Questo articolo definisce i criteri di logging in conformità agli standard internazionali (iso/iec 27001:2022, nist), e alle normative vigenti (gdpr, Provvedimenti Garante Privacy italiano) mettendo in luce alcune contraddizioni fra i recenti provvedimenti sanzionatori del GPDP relativi ad una ipotizzata eccessiva conservazione dei log in quanto lesivi dei diritti e delle libertà del personale dipendente e non, soprattutto attraverso la lettura dell’Articolo 4 dello Statuto dei Lavoratori che vieta il monitoraggio dell’attività lavorativa in determinati contesti.

Come si vedrà nel seguito, gli standard e le best practice di sicurezza informatica consigliano la conservazione dei log per 6-12 mesi, mentre il nostro GPDP non ammette conservazione dei log oltre i 30 giorni, salvo non stipulare apposito accordo sindacale (cosa non sempre fattibile e comunque onerosa per l’azienda).

1. Riferimenti standard internazionali

La gestione dei log è regolata da diversi framework che offrono prospettive complementari, dalla conformità alla resilienza operativa.

• ISO/IEC 27001:2022:
  • Controllo 8.15 (logging): Richiede la produzione, conservazione e protezione dei log di eventi, eccezioni e guasti. I log devono essere analizzati regolarmente per rilevare attività sospette.
  • Controllo 8.16 (monitoring activities): Introduce il monitoraggio attivo di reti, sistemi e applicazioni per comportamenti anomali.
  • Controllo 8.17 (clock synchronization): Obbliga alla sincronizzazione temporale (ntp) per garantire la coerenza dei timestamp.
• NIST SP 800-92 (Guide to computer security log management):
  • Fornisce linee guida dettagliate sulla gestione del ciclo di vita dei log. Suggerisce di bilanciare la capacità di archiviazione con la necessità di analisi storica, raccomandando una conservazione a lungo termine per identificare attacchi persistenti (apt).
• NIST SP 800-53 Rev. 5 (Audit and accountability – family au):
  • Specifica controlli rigorosi sulla generazione dei record di audit (AU-2), sulla protezione delle informazioni di audit (AU-9) e sulla durata della conservazione (AU-11), richiedendo che i periodi di ritenzione siano legati alle esigenze di indagine e alle policy legali.

2. Tempi di conservazione consigliati e obbligatori

Nella tabella seguente sono riepilogati i tempi di conservazione dei log secondo alcuni standard normativi.

Utenti standard (business users)

Tipologia log	Standard/Normativa	Tempo di conservazione
Amministratori di sistema	Garante Privacy (Provv. 2008)	Minimo 6 mesi (log di accesso e log-off)
Transazioni finanziarie	Pci dss 4.0	1 anno (di cui almeno 3 mesi online)
Dati di traffico telefonico/telematico	Normativa nazionale (Italia)	Fino a 6 anni (per accertamento reati)
Metadati e-mail (lavoratori)	Garante Privacy (Provv. 2024)	21 giorni (estensibili solo con accordo sindacale/dpia)
Log di sicurezza (firewall, ids)	NIST/best practice	6 – 12 mesi (per analisi trend e APT)

3. Cosa tracciare: utenti standard vs. amministratori

L’obiettivo è rilevare compromissioni di account (phishing) e insider threat.

• Eventi di autenticazione: Successo, fallimento, origine geografica/ip.
• Accesso alle risorse: Lettura/scrittura su file sensibili, accesso a database critici.
• Utilizzo applicativo: Funzioni critiche eseguite (es. esportazione massiva di contatti).
• Web proxy: Siti visitati per rilevare comunicazione con server c2 (command & control).

Amministratori di sistema (privileged users)

L’obiettivo è prevenire abusi di privilegio e garantire l’accountability.

• Gestione account: Creazione, modifica permessi, reset password di altri utenti.
• Modifiche di sistema: Modifica dei file di configurazione, installazione di nuovi servizi/software.
• Accesso ai log: Tentativi di lettura o cancellazione dei file di log (segno tipico di copertura delle tracce).
• Esecuzione comandi: Tracciamento integrale dei comandi eseguiti con privilegi elevati (es. sudo, powershell con privilegi).

4. Metodologia di analisi incidenti (l.e. 5 W)

In caso di violazione, i log devono permettere di rispondere a:

1. Who (chi): Identificazione univoca del soggetto (account id).
2. What (cosa): L’azione specifica (es. “cancellazione db”).
3. When (quando): Timestamp preciso e sincronizzato (8.17).
4. Where (dove): Asset coinvolto e indirizzo ip (interno/esterno).
5. Why/How (come): Il metodo utilizzato (es. “sfruttamento vulnerabilità cve-2023-xxxx”).

5. Protezione e integrità (anti-tampering)

Secondo il controllo 8.15 e lo standard NIST SP 800-92, i log devono essere protetti:

• Centralizzazione: Inviare i log in tempo reale a un server centralizzato (siem/syslog server).
• Append-only: Configurazione dello storage affinché i dati possano solo essere aggiunti e mai modificati.
• Crittografia e firma: Garantire l’autenticità dei log per renderli validi come prova legale.

6. Dati personali e tecniche di protezione (privacy by design)

I log contengono spesso dati personali (indirizzi IP riconducibili univocamente a utenti interni, nomi utente, email, identificativi di sessione). Il GDPR impone di ridurre il trattamento di tali dati al minimo necessario.

Tecniche di protezione e implementazione tecnica

• Pseudonimizzazione tramite hashing con salt: Si sostituisce l’identificativo con un codice hash generato aggiungendo un salt (una stringa casuale segreta) al dato originale.
  • Applicazione pratica: Nello stack ELK (Elasticsearch, Logstash, Kibana), si utilizza il filtro fingerprint di logstash. Anche Splunk permette di trasformare i dati in fase di ingestione tramite script o espressioni regolari (sed).
• Mascheramento dinamico (masking): Nasconde parti del dato (es. 192.168.*.*) per la maggior parte degli operatori.
  • Applicazione pratica: Microsoft Sentinel utilizza le “data collection rules” (dcr) per mascherare i dati PII prima della scrittura.
• Tokenizzazione: Sostituzione del dato sensibile con un “token” non correlato matematicamente.

Difficoltà ed onerosità per l’organizzazione

1. Complessità amministrativa (alta): Gestire in sicurezza le chiavi di de-pseudonimizzazione o i salt è critico.
2. Costo computazionale (medio): L’esecuzione di funzioni di hash su milioni di eventi richiede maggiore potenza di calcolo (cpu).
3. Impatto sull’efficacia investigativa (critico): L’anonimizzazione irreversibile impedisce la ricostruzione degli incidenti. La pseudonimizzazione è il miglior compromesso.
4. Manutenzione (media): Necessità di aggiornamento costante per identificare nuovi campi contenenti dati personali.

7. Conclusioni

Un’erronea interpretazione dello Statuto dei Lavoratori del 1970 (ignorando le modifiche apportate dal Jobs Act) da parte del GPDP potrebbe penalizzare le aziende che desiderano incrementare la propria sicurezza informatica, anche a fronte dei crescenti obblighi derivanti dalla Direttiva NIS 2e dalla necessità di soddisfare le richieste di Committenti importanti (comprese alcune P.A.) di implementare il sistema di gestione per la sicurezza delle informazioni ISO 27001. Sarebbe importante instaurare un tavolo di lavoro congiunto fra Autorità garante per la Protezione dei Dati Personali, ACN ed Associazioni che si occupano di Sicurezza informatica come il CLusit, oltre ad esperti del settore per evitare che, come avvenuto in passato per altri argomenti, i diversi Enti percorrano strade parallele senza condividere le conoscenze.