I log di sicurezza servono a riconoscere comportamenti anomali e ricostruire ciò che è accaduto. Per renderli utilizzabili occorre progettare l’intera catena: evento generato, trasmissione, conservazione, ricerca e decisione dell’analista. Una piattaforma che raccoglie milioni di righe senza un responsabile della presa in carico può aumentare costi e dati personali trattati senza migliorare la risposta agli incidenti.
Il riferimento ANSSI sull’architettura di journalisation distingue l’uso dei registri per rilevare incidenti e per ricostruirli successivamente. Questa guida adatta tale percorso a un’organizzazione italiana: definire gli eventi necessari, proteggerne integrità e accessibilità, motivare la conservazione e verificare che un allarme raggiunga davvero chi deve agire.
Partire dalle domande dell’indagine
Prima di acquistare spazio di archiviazione, elencate le domande cui dovrete rispondere. Chi ha aperto un fascicolo? Da quale account è stato esportato un elenco? Quando è cambiato un privilegio? Un tentativo di autenticazione è fallito oppure una sessione già valida è stata utilizzata in modo improprio? Le risposte richiedono sorgenti diverse, che non sempre sono abilitate automaticamente.
Collegate le sorgenti alla mappatura dei sistemi e dei flussi. Per ogni applicazione importante individuate gli eventi disponibili, il referente, le limitazioni di esportazione e il percorso verso il collettore. Includete i servizi esterni: sapere che il fornitore conserva i log non significa poterli ottenere tempestivamente, nel formato necessario e per l’intervallo utile.
Distinguete eventi di autenticazione, attività applicative, modifiche amministrative e anomalie di sistema. Un accesso riuscito non dimostra che sia stato consultato un determinato documento. Viceversa, un evento applicativo privo di identità attendibile rende difficile attribuire l’operazione. La progettazione deve esplicitare questi limiti e valutare come ridurli.
Definire uno schema degli eventi
Una riga utile contiene un riferimento temporale interpretabile, una sorgente riconoscibile, un tipo di evento e un risultato. Quando necessario, aggiunge identificativo dell’account, oggetto dell’operazione e correlazione con altri passaggi. Preferite identificativi stabili ai nomi visualizzati, che possono cambiare o essere condivisi da più persone.
| Campo | Domanda da risolvere | Controllo sul campione |
|---|---|---|
| Tempo | Quando è avvenuto l’evento? | Fuso orario e sincronizzazione noti |
| Sorgente | Quale componente lo ha generato? | Identificativo presente nell’inventario |
| Attore | Quale identità ha agito? | Account distinguibile e collegabile al ruolo |
| Operazione | Che cosa è stato tentato? | Codice evento documentato |
| Esito | L’operazione è riuscita? | Fallimenti separati dai successi |
| Oggetto | Quale risorsa è coinvolta? | Riferimento sufficiente senza copiarne il contenuto |
Non inserite nei log password, token di sessione, chiavi private o contenuti integrali quando basta un riferimento. Anche un messaggio di errore può contenere un dato sanitario o una stringa di connessione. Usate dati sintetici per verificare il comportamento delle applicazioni e controllate gli output effettivi, comprese eccezioni, tracciamenti di debug ed esportazioni diagnostiche.
La minimizzazione dei dati riguarda anche la raccolta tecnica. Per ogni campo aggiuntivo chiedete quale analisi consenta e chi la svolgerà. Se nessuno sa giustificarne l’utilità, rimuovetelo o limitatene l’attivazione a un’indagine autorizzata, con condizioni e durata documentate.
Un esempio interamente sintetico rende verificabile lo schema: 2026-09-09T08:15:00Z; sorgente=PORTALE-01; attore=UT-042; operazione=EXPORT; oggetto=RICHIESTA-218; esito=DENIED; correlazione=EV-903. L’analista può cercare il tentativo negato e collegarlo alla richiesta; il record non contiene il documento, la password o il token della sessione. Nell’esercitazione si verifica che il collettore mantenga il significato di DENIED e lo stesso riferimento temporale. Se l’applicazione registra soltanto l’accesso all’account, questo evento non può essere ricavato per supposizione: la lacuna va dichiarata e affrontata alla sorgente.
Progettare raccolta e trasmissione
La centralizzazione può proteggere i registri dalla cancellazione sul sistema compromesso e facilitare la correlazione. Deve però essere accompagnata da autenticazione delle sorgenti, protezione dei collegamenti e controllo dei privilegi sul collettore. Un archivio centrale accessibile con le stesse credenziali amministrative del sistema sorgente può condividere il medesimo punto di compromissione.
Definite il comportamento in caso di interruzione: buffering locale, capacità disponibile, ordine di invio e rilevamento delle perdite. Se una sorgente smette di trasmettere, deve essere possibile distinguere un’assenza normale di eventi da un guasto. Monitorate anche ritardi e duplicati, perché una ricerca corretta su un periodo può risultare incompleta quando i dati arrivano successivamente.
Documentate quali normalizzazioni vengono applicate. Conservare il significato dell’evento è essenziale: una conversione sbagliata del fuso orario può invertire la sequenza di un attacco. Se mantenete una versione originale e una elaborata, chiarite finalità, accessi e conservazione di entrambe. La duplicazione deve rispondere a una necessità concreta.
Rendere verificabili integrità e accessi
Separate chi amministra il sistema osservato da chi può modificare o cancellare l’archivio dei log, quando il rischio e l’organizzazione lo richiedono. Limitate le operazioni distruttive e tracciatele. L’inalterabilità non si ottiene scrivendo la parola nel contratto: occorre conoscere le funzionalità applicate, i privilegi che possono aggirarle e le evidenze della loro attivazione.
Durante una verifica, esportate un campione e ricostruite la sua provenienza. Annotate soggetto che esegue l’estrazione, criteri, intervallo e destinazione. Una copia consegnata a un consulente è un ulteriore trattamento e richiede protezione. Utilizzate canali e accessi coerenti con il contenuto; non inoltrate interi archivi a una casella condivisa per comodità.
Gli accessi privilegiati richiedono un esame specifico anche nel quadro italiano degli amministratori di sistema. Quel perimetro non va confuso con tutti i log applicativi dell’organizzazione. Analogamente, i metadati della posta dei lavoratori hanno una disciplina contestuale che merita una valutazione distinta.
Motivare la conservazione per finalità
Il GDPR non stabilisce una durata unica per ogni registro tecnico. L’articolo 5 e l’articolo 32 richiedono rispettivamente limitazione della conservazione e sicurezza adeguata. Occorre considerare la funzione concreta del log, i rischi, eventuali regole settoriali e le esigenze documentate di analisi. Copiare una durata da una guida straniera senza valutarne l’ambito produce una motivazione fragile.
Create categorie separate: autenticazione, amministrazione, accessi a fascicoli, traffico tecnico e diagnostica. Per ciascuna indicate inizio del periodo, durata ordinaria, modalità di cancellazione e condizioni di congelamento per un incidente. La politica dei tempi di conservazione deve includere anche copie esportate, archivi di indagine e dati nel servizio del fornitore.
Verificate l’esecuzione della cancellazione con un campione temporale. Un’impostazione della console non dimostra che indici secondari o esportazioni seguano la stessa regola. Se una porzione viene trattenuta per un contenzioso o un’indagine, delimitatela e documentate il riesame; il congelamento dell’intero archivio per tempo indefinito è una scelta diversa e più invasiva.
Collegare gli allarmi a una risposta
Scegliete poche rilevazioni iniziali che abbiano un proprietario: aumento anomalo dei fallimenti, modifica di privilegi, esportazione inattesa o disattivazione di una sorgente. Per ogni regola precisate soglia, contesto, destinatario e azione iniziale. Una soglia produce un sospetto, non una conclusione automatica sulla persona interessata.
Eseguite un’esercitazione controllata con eventi sintetici. Verificate generazione, arrivo, correlazione, apertura della segnalazione e conferma di presa in carico. Misurate il tempo tra questi passaggi e registrate dove l’informazione perde significato. Se l’analista non dispone del referente applicativo o della documentazione dei codici evento, il problema non si risolve aumentando la quantità raccolta.
Quando emerge una possibile compromissione di dati personali, collegate l’indagine alla procedura di gestione della violazione. La raccolta tecnica deve aiutare a valutare dati coinvolti, persone, conseguenze e misure; non deve ritardare artificialmente l’esame degli obblighi di notifica.
Il fascicolo del sistema di logging può quindi comprendere catalogo delle sorgenti, schema eventi, configurazioni, responsabilità, matrice di conservazione e verbale dell’esercitazione. Riesaminatelo quando cambiano applicazioni, fornitori o modalità di accesso. La prova più convincente resta la capacità di seguire un evento dall’origine alla decisione, spiegando anche ciò che il sistema non consente di sapere.
Per un servizio affidato all’esterno, chiedete inoltre una simulazione di consegna delle evidenze. Concordate il formato, il significato dei campi, la gestione dei fusi orari e il contatto disponibile durante un incidente. Un file tecnicamente esportabile può essere inutilizzabile se richiede una licenza cessata o un interprete proprietario non più accessibile. Inserite la disponibilità dei log nella verifica di uscita dal contratto, distinguendo i dati necessari all’organizzazione da quelli che il fornitore deve conservare per proprie finalità documentate. Questa preparazione riduce le dipendenze proprio quando il rapporto commerciale è in difficoltà.