Il 21 ottobre, quando PHP2Shell è diventato pubblico, il team di threat intelligence di Amazon ha pubblicato una riga che ogni incident responder avrebbe dovuto leggere due volte: investigare a partire almeno dal 17 ottobre. Quattro giorni prima della divulgazione.
Ecco quindi una domanda per il vostro team. Avete ancora i log del web server del 17 ottobre?
Se ruotano ogni sette giorni, la risposta onesta a «siamo stati colpiti prima che qualcuno ne fosse a conoscenza?» è «non lo sapremo mai».
Ora chiedete al vostro DPO per quanto tempo dovreste conservare quei log. Risposta diversa. Sono pieni di indirizzi IP, ID utente, dati di sessione, a volte interi corpi di richiesta. Dati personali, conservati per una finalità di sicurezza che nessuno ha scritto, per un periodo che nessuno ha scelto.
Gli stessi log, due persone, due timori. Entrambi legittimi.
Due dogmi allo stesso tavolo
Il dogma della sicurezza: registrare tutto, conservarlo per sempre, lo storage è economico e non si sa mai. Deriva da una ferita reale. Ogni incident responder si è imbattuto nel vicolo cieco in cui la traccia si interrompe perché i log sono stati sovrascritti la settimana prima.
Il dogma della privacy: registrare il meno possibile, per il minor tempo possibile. Anche questa è una ferita reale. Un archivio di log che conserva tutto su tutti a tempo indeterminato diventa un database di sorveglianza e uno dei bersagli più appetibili dell'azienda. La CNIL ha citato esattamente questo rischio nella propria guida: volumi di dati di log abbastanza grandi da essere attaccati o utilizzati per finalità che nessuno aveva previsto.
Ciascuna parte ha ragione riguardo al proprio rischio. Nessuna delle due funziona come impostazione predefinita. «Per sempre» non è un periodo di conservazione, e nemmeno «il meno possibile».
Aneddoto: In pratica, al quel tavolo c'è raramente una seconda persona. Negli audit ISO 27001 che conduco, il DPO non viene quasi mai consultato sulla registrazione dei log. Mi sorprende ogni volta ed è una delle non conformità minori che rilevo più spesso. Il team di sicurezza sceglie un periodo di conservazione, lo strumento lo applica, e la persona il cui compito è chiedersi «perché conserviamo questo?» lo scopre durante l'audit. L'articolo 38 del GDPR richiede già che il DPO sia coinvolto, in modo adeguato e tempestivo, in ogni questione riguardante i dati personali. I log sono una di esse.
Cosa dicono davvero i testi
Ecco cosa rompe lo stallo. Nessun regolamento fornisce un numero universale. E tutti chiedono la stessa cosa.
GDPR chiede minimizzazione dei dati e limitazione della conservazione. Richiede inoltre misure di sicurezza adeguate ai sensi dell'articolo 32, e il Considerando 49 riconosce il trattamento strettamente necessario e proporzionato per la sicurezza delle reti e delle informazioni come interesse legittimo. Quindi la registrazione è lecita. È la registrazione senza una finalità definita a creare problemi.
La raccomandazione della CNIL del 2021, uno dei documenti di orientamento dei regolatori più dettagliati sull'argomento, prevede da sei mesi a un anno per i log applicativi che tracciano chi ha acceduto e modificato cosa. Un periodo più lungo è possibile con una giustificazione, fino a tre anni nei casi comuni. Quando i dati sottostanti vengono conservati meno di sei mesi, i log non dovrebbero contenere quei dati personali. E lascia esplicitamente fuori dal proprio ambito i log perimetrali, di firewall e apparati di rete. Quasi tutti coloro che citano «sei mesi» si perdono questa parte.
Il Regolamento di esecuzione NIS2 2024/2690, per i provider di infrastrutture e servizi digitali che rientrano nel suo campo di applicazione, richiede un elenco basato sul rischio degli asset da registrare, revisione periodica, protezione contro le manomissioni e conservazione per un periodo predefinito. Nessun minimo. La guida all'implementazione di ENISA aggiunge poi due righe: eliminare i dati alla scadenza del periodo di conservazione, e non conservare nei log dati il cui periodo di conservazione sia già scaduto.
Rileggete. Il regolatore della sicurezza dice la stessa cosa del regolatore della privacy.
AI Act fissa un minimo invece di un massimo. I deployer di sistemi ad alto rischio dovranno conservare i log generati da tali sistemi per almeno sei mesi.
PCI DSS richiede dodici mesi di storico, di cui tre immediatamente disponibili. Un numero contrattuale, non legale.
Cinque fonti, cinque risposte, un'unica esigenza comune: un periodo definito, legato a una finalità, messo per iscritto.
Decidere in base alla finalità
L'errore abituale è stabilire la conservazione per strumento. «Il SIEM conserva 90 giorni» è una decisione di licenza travestita da decisione di sicurezza.
Stabilirla per finalità.
Il rilevamento richiede dati recenti e ricercabili. Settimane, conservati a caldo.
L'investigazione richiede uno storico sufficiente a coprire il tempo realisticamente necessario per scoprire una compromissione, più la finestra pre-divulgazione che PHP2Shell ha appena dimostrato. Un rilevamento lento comporta una conservazione lunga. Questo è il compromesso onesto.
L'accountability per gli accessi privilegiati richiede una traccia più lunga, perché «chi ha fatto questo, e ne aveva il diritto?» emerge solitamente mesi dopo.
Gli obblighi legali e contrattuali fissano il proprio minimo. Si seguono.
Un log può servire diverse finalità. La sua conservazione è determinata dalla finalità più esigente che si è effettivamente in grado di giustificare, non da quella che si vorrebbe avere.
Tre leve che dissolvono la maggior parte del conflitto
La conservazione è una sola manopola. La maggior parte del conflitto scompare una volta che si usano le altre due.
Contenuto. Registrare l'evento, escludere il dato. Chi, quale azione, quando, quale riferimento al record. Omettere il record stesso, il corpo della richiesta, il campo in cui qualcuno ha digitato una password per sbaglio. I log verbose e di debug sono i luoghi in cui i dati personali fuoriescono in aree che nessuno governa: assegnar loro una vita misurata in giorni.
Livelli. Un livello caldo breve per il rilevamento. Un livello freddo più lungo per l'investigazione, cifrato e di accesso più difficile. Un archivio ristretto per le tracce la cui conservazione pluriennale si è giustificata. A ogni livello inferiore, meno persone possono leggerlo.
Accesso. L'archivio dei log è probabilmente il registro più completo dell'attività personale in azienda. Trattatelo di conseguenza. Ruoli nominativi, accesso ai log stesso registrato, e amministratori che non possono modificare in modo silenzioso la propria traccia.
E un guardrail. Un log di sicurezza viene raccolto per la sicurezza. Il giorno in cui viene estratto per una controversia HR senza una base giuridica separata e un'adeguata trasparenza, si è cambiata la sua finalità; e in diversi paesi si è anche fatto entrare nella stanza il consiglio dei lavoratori.
Un esempio di tabella di conservazione
Adattatela alla vostra valutazione del rischio e alla vostra normativa nazionale. È un punto di partenza e mostra il ragionamento che sarà necessario documentare.
| Tipo di log | Finalità | Conservazione di esempio | Giustificazione |
|---|---|---|---|
| Firewall, proxy, DNS, VPN | Rilevamento, investigazione | 12 mesi, 90 giorni a caldo | Copre le finestre di rilevamento tardivo e di sfruttamento pre-divulgazione |
| Autenticazione (SSO, directory, MFA) | Rilevamento, investigazione su compromissione | 12 mesi | La compromissione di un account raramente si annuncia il primo giorno |
| Azioni privilegiate e di amministrazione | Accountability, controllo interno | Fino a 3 anni, accesso ristretto | Esigenza di controllo interno documentata, entro il limite massimo della CNIL |
| Accesso applicativo a dati personali | Tracciabilità | Da 6 a 12 mesi | Intervallo di riferimento CNIL |
| Applicazioni con dati a breve durata | Tracciabilità | Da 6 a 12 mesi, senza i dati personali stessi | I log non devono sopravvivere ai dati che descrivono |
| Log applicativi debug e verbose | Troubleshooting | Da giorni a settimane | Nessuna finalità oltre alla risoluzione del bug |
| Ambiente carte di pagamento | PCI DSS | 12 mesi, 3 online | Requisito contrattuale |
Mettere la decisione per iscritto
Sul controllo A.8.15, l'auditor chiederà per quanto tempo conservate i vostri log. I migliori poi chiedono perché.
La risposta deve esistere prima della domanda. Una policy di logging con la tabella di conservazione e la relativa giustificazione. Una valutazione dell'interesse legittimo per la registrazione stessa. Il logging elencato nel registro delle attività di trattamento, perché è un'attività di trattamento. Il parere del DPO agli atti. Un owner nominato. Una data di revisione.
Quell'insieme di documenti è ciò che trasforma un dogma in una decisione. La sicurezza ottiene la traccia di cui ha bisogno. La privacy ottiene una finalità, un limite e una data di cancellazione. E quando qualcuno mette in discussione una delle due parti, in fondo c'è una firma.
Considerazione finale
Il conflitto tra «conservare tutto» e «non conservare nulla» di solito si risolve a favore di chi argomenta più a voce alta, e il periodo di conservazione finisce per essere quello con cui lo strumento è stato consegnato.
Nessuno dei due regimi vi lascia uscire così facilmente. Entrambi vogliono vedere che qualcuno ha esaminato la finalità, scelto un numero e scritto il perché.
Richiede un pomeriggio. Vi risparmia due conversazioni: spiegare a una società di incident response che i log necessari erano stati cancellati per impostazione predefinita, e spiegare a un'autorità di protezione dei dati perché avete conservato sette anni di tutto.
Entrambi i lati di questa questione sono trattati in due dei nostri corsi. ISO 27001 Lead Implementer affronta il logging e il monitoraggio come controlli di cui si può fornire evidenza in audit. ISO 27701 Lead Implementer affronta il lato privacy: finalità, conservazione e i documenti che le giustificano.