LOG MANAGEMENT: LA VISIONE DEL CLIENTE

Il log è il grande protagonista della scena informatica che supporta gli addetti ai lavori nel campo dell’Information Technology in tutte le fasi del processo di produzione del software (svillupo, test ed esercizio).
Ciò nonostante solo recentemente ha visto le luci della ribalta grazie ad alcuni provvedimenti del legislatore (ad esempio garante privacy 196/2003 e provvedimento amministratori di sistema doc web 1577499 e del 25/06/2009 doc web 1626585)e grazie all’adozione in molte aziende di standard internazionali di controllo come il PCI-DSS o il SOX.
L’implementazione di un sistema di log management in azienda rappresenta molto spesso una chimera irraggiungibile a causa dell’assenza di attività propedeutiche che ne costituiscono le fondamenta e a causa di una definizione non chiara degli obiettivi di progetto. Cerchiamo quindi di fare un po’ di ordine partendo da quest’ultimo aspetto.
I sistemi di log management sono di due tipologie:
1) Event Management System
2) Information Management System
Gli obiettivi che si prefiggono le due categorie di sistemi sono profondamente diversi;
Un EMS ha l’obiettivo di trovare all’interno di una grossa mole di dati delle informazioni volte ad individuare degli incident di sicurezza utilizzando come fonte di dati sistemi di IDS/IPS, log su apparati di rete o sistemi. Si tratta di utilizzare query tipo data-mining con meccanismi di correlazione per individuare degli “schemi nel caos” legati a malware e/o possibili attacchi.
Un IMS è una soluzione di controllo accessi che consente la generazione, il collezionamento, l’analisi e la conservazione dei file di log in modo da preservare la confidenzialità, la integrità e la disponibilità dei file di log. Intendendo con file di log un file contente un identificativo associabile univocamente ad una persona fisica, dei riferimenti temporali ed il comando o la query effettuata.
Dal punto di vista tecnologico le due suddette tipologie potrebbero avere elementi in comune ciò nonostante è bene affrontare le due tematiche separatamente in progetti distinti salvo poi riutilizzare le componenti comuni (ad esempio log collection, log parsing etc etc).
In questa sede si affronteranno le problematiche connesse ad un IMS evidenziando tutte le fasi di progetto necessarie per la buona riuscita di quest’ultimo. Il primo classico errore è quello di pensare che una soluzione di log management sia basata esclusivamente sull’installazione e configurazione di un pacchetto software.
Un IMS nasce invece da due esigenze:
1) Compliance con le policy interne e/o con normative esterne (PCI-DSS, SOX, provvedimenti del garante della privacy)
2) Necessità di conservare delle prove informatiche per tutelarsi da eventuali attività illecite fatte da dipendenti o terze parti sui dati personali dei clienti.
La soluzione IMS che dovrà essere implementata è fortemente legata alla chiara definizione dei suddetti obbiettivi.
Censimento e Bonifica Utenze
Qualora in azienda sia stato già messo in campo una soluzione di Identity e Access Management, si parte già con il piede giusto altrimenti è necessario prevedere una fase di censimento e bonifica utenze. Un presupposto per la buona riuscita dell’implementazione di un IMS è che tutti le user name aziendali siano riconducibili ad una persona fisica. Anche gli account di gruppo o quelli applicativi qualora non possano essere sostituiti con user name personali devono essere associati ad un impiegato.
In presenza di user name di gruppo occorre, nei limiti del possibile, non consentire l’accesso diretto ai sistemi con tali account obbligando l’utente ad identificarsi con la propria user name personale e successivamente utilizzando l’account applicativo o di gruppo. Occorre predisporre sui sistemi delle black list (o delle allow list) forzando l’accesso con account personale.
Generazione dei LOG
Risolto il problema dell’autenticazione è necessario definire chiaramente come verranno generati i log quando non sono già presenti sui sistemi. Il problema non è affatto banale perché tale attività, il più delle volte, deve essere effettuata su sistemi in esercizio non progettati in ottica di log management e quindi la soluzione migliore è quella che non darà impatti sul sistema e sul processo di business che il sistema supporta.
Lungi dal voler fare una disamina di tutti i possibili generatori di log sui sistemi informatici, si ritiene utile citare i tre sistemi di base:
1) Log di Oracle
2) Log di Windows
3) Log di Unix/Linux
Per quanto riguarda Oracle la difficoltà sta tutta nel cercare di minimizzare gli impatti sull’utenza facendo i conti con le diverse versioni del DBMS in esercizio. Oracle mette a disposizione la feature chiamata FGA (Fine Grain Audit) che consente la registrazione degli accessi a tabelle con dati personali con livello di dettaglio personalizzabile. Una soluzione alternativa passa dall’installazione di network appliance utilizzando lo span delle porte dello switch di rete (alcuni esempi sono Imperva e DB Gardium). La scelta è funzione della versione dei DBMS in esercizio, delle risorse hw disponibili e del budget a disposizione (visto il costo non indifferente degli appliance citati).
Con Windows bisogna fare i conti con un sistema operativo che traccia pochissimo di default, che salva le informazioni in formato binario e con alcune difficoltà a tracciare le attività legate all’accesso via controllo remoto. La soluzione in questo caso passa dall’installazione di prodotti di mercato che forniscono degli agent ed una consolle per la produzione di report con gli accessi al sistema ed agli oggetti del file system. A tale soluzione va affiancato un appliance control box (un esempio è Balabit) che registra le sessioni di controllo remoto della piattaforma.
Unix/Linux presenta decisamente meno problemi. La soluzione adottata in BT Italia è quella meno invasiva ovvero una shell ad hoc che scrive in un file tutti i comandi digitati all’interno di una sessione ssh.

Collection e Conservazione
Per la collection dei file di log c’e’ la modalità push che prevede l’invio del file dal server al repository centrale una volta chiusa la sessione e la modalità pull che prevede invece che il trasferimento del file sia comandato centralmente. La modalità pull ha come vantaggio una maggiore semplicità di gestione mentre la modalità push una migliore garanzia circa l’integrità del file.
Fonte BT Italia

In figura il processo utilizzato in BT Italia per garantire l’integrità del file di log ovvero per evitare che il file di log generato dal sistema non sia modificato in periodi successivi all’atto della sua creazione. Esistono soluzioni di mercato alternative che tuttavia seguono lo stesso principio qui descritto.
Su ogni file di log, nel più breve tempo possibile (il garante della privacy suggerisce al massimo ogni 15 minuti) una volta prelevato dal sistema di origine deve essere eseguita:
• Il calcolo della stringa di hash (algoritmo di hashing MD5 o SH1);
• marca temporale con un timestamp server (identificativo con ora, minuti, secondi, giorno, mese e anno) che marca temporalmente l’hash ricevuto effettuandone, nel contempo, la firma digitale (6).
A questo punto si effettua la memorizzazione dei tre elementi: file di Log, stringa di hash e marca temporale (7); tramite gli ultimi due sarà possibile verificare l’attendibilità del file di log memorizzato.
Si precisa che tale processo è una possibile archiviazione elettronica che ancora non risulta conforme a quanto previsto dalle norme tecniche per la conservazione sostitutiva previste dalla deliberazione CNIPA n. 11/2004 e nel DPCM 13 gennaio 2004. In altri termini non è sufficiente per produrre in giudizio un file di log ma è più che sufficiente ai fini di compliance.

Il LOG come Prova Informatica
Secondo la suddetta legislazione, la conformità dell’immagine trasposta su supporto di memorizzazione rispetto al documento d’origine deve essere garantita dal “responsabile della conservazione” mediante l’apposizione della propria firma digitale (ad esempio firmando la codifica hash del file).
La conservazione sostitutiva legale è quel processo informatico che “rende legali” i documenti archiviati digitalmente sia a livello fiscale, sia a livello civile.
Il responsabile del procedimento di conservazione sostitutiva ha diverse responsabilità tra le quali quella di adottare le misure necessarie per la sicurezza fisica e logica del sistema preposto al processo di conservazione sostitutiva e delle copie di sicurezza dei supporti di memorizzazione;
C’e da dire tuttavia che in sede di giudizio un’eventuale consulenza tecnica di ufficio disposta dal giudice istruttore dovrebbe verificare, oltre alle modalità di conservazione della prova, anche le modalità procedurali e organizzative con cui viene gestita l’autenticazione di un dipendente. In altri termini l’autenticazione debole (User name e password) utilizzata nella grande maggioranza dei casi in azienda non garantisce l’identificazione certa del dipendente.
L’autenticazione debole utilizzata dagli incaricati del trattamento dei dati oggetto di contenzioso deve essere conforme alle misure minime di sicurezza descritte all’allegato B del codice Privacy (196/2003) e deve esistere un processo formalizzato all’interno del Documento Programmatico della Sicurezza per la gestione dei rischi tra i quali quello del furto della password.

Interfaccia grafica di interrogazione
L’implementazione di un’interfaccia grafica per l’interrogazione dei file di log o per la produzione di reportistica relativa agli accessi ai sistemi è una conseguenza della necessità di effettuare un monitoraggio degli accessi verificando che questi siano conformi con quanto previsto dalle lettere di nomina degli incaricati al trattamento dei dati o degli amministratori di sistema.
Tale necessità come pure la presenza di una struttura operativa che effettui il controllo dei file di log è spesso richiesta dalle policy interne di multinazionali come BT o da standard di controllo aziendale come la PCI-DSS ed è comunque consigliabile l’implementazione a prescindere dal requisito esplicito.
Dal punto di vista dell’implementazione si è sempre di fronte al solito dilemma del “make or buy”. Di sicuro prodotti software che effettuano interrogazioni o report su file di log non mancano sul mercato ma occorre prestare particolare attenzione alle funzionalità richieste. Ad esempio qualora si volesse integrare la lettera di nomina degli amministratori di sistema con la definizione dell’ambito applicativo associato ad ogni incaricato del trattamento i costi di customizzazione di un pacchetto software potrebbero far preferire una soluzione make.