L’utilizzo di un sistema di log management è dettato dalla necessità di poter aggregare e conservare a norma di legge tutti i log di un certo interesse prodotti da sistemi informativi eterogenei, con lo scopo di garantire la sicurezza dei sistemi stessi.
Una necessità ancora più stringente dal momento che, con le attuali tecnologie, la quantità di informazioni scambiate tra i sistemi è enorme. Ed il passo da un sistema di pura aggregazione di log che possiamo definire SIM (Security Information Management) a qualcosa di più evoluto come un SIEM (Security Information and Event Management) è breve.
L’analisi dei log prodotti dai sistemi, la cui gestione rientra nelle responsabilità dell’amministratore di un sistema informativo, è sempre stato un problema annoso diventato poi in parte obbligo di legge in seguito all’introduzione del decreto del 27 novembre 2008 e tornato quanto mai in auge con l’entrata in vigore del nuovo regolamento europeo sulla protezione dei dati personali (Regolamento EU 679/2016 o GDPR).
Indice degli argomenti
Sistema di log management: architettura di base
Andiamo con ordine e descriviamo enciclopedicamente un sistema di log management nelle sue parti essenziali.
Il primo passo è proprio l’individuazione del log, che possiamo classificare come una registrazione cronologica delle azioni effettuate da un utente in un sistema informatico. Risulta di fondamentale importanza capire e decidere quali tipi di informazioni (e con quale dettaglio) la singola unità che fa parte della nostra architettura debba spedire al server che si occupa di collezionare tutte le informazioni.
Sicuramente uno dei parametri principe per il corretto funzionamento è la dimensione dei volumi di dati che verranno gestiti ed è innegabile che questo sia legato anche alle scelte delle informazioni che decido di raccogliere da ogni singolo componente del mio sistema. È essenziale, poi, che tutti i sistemi siano sincronizzati temporalmente per far sì che la cronologia delle azioni venga fedelmente mantenuta. Per garantire una corretta registrazione degli eventi, l’orario interno dei sistemi deve essere sincronizzato con i time server di Stratum 0, disponibili pubblicamente a tale scopo, tramite protocollo NTP (Network Time Protocol).
Log management: normalizzazione dei dati raccolti
Altro fattore fondamentale per una corretta gestione delle informazioni è la successiva normalizzazione dei dati raccolti, compito affidato al collettore centrale del sistema (logger). In questo modo è possibile “tradurre” diversi tipi di informazione che posseggono schemi differenti standardizzandoli.
Questo processo è fondamentale nel momento in cui si voglia poi analizzare e soprattutto “correlare” quanto raccolto. La maggior parte dei prodotti presenti sul mercato (sia commerciali che open source) si compone di agent installati sui singoli elementi del sistema e di un collettore centrale che ha il compito di ricevere e normalizzare il log per le successive analisi. Ulteriore compito affidato al server/collettore è quello di conservare in modalità sicura ed immutabile le informazioni.
Tutto questo sarebbe già sufficiente ad ottemperare al decreto del Garante per la protezione dei dati personali relativo agli amministratori di sistema, pubblicato sulla Gazzetta Ufficiale n.300 del 24 dicembre 2008 e nel quale si sancisce che ogni azienda, dopo aver individuato i sistemi che contengono i dati più critici, deve prima di tutto nominarne gli amministratori e quindi dotarsi di un sistema di log management che sia in grado di tracciare gli accessi degli operatori ai dispositivi ed alle applicazioni che gestiscono.
Il sistema deve conservare i dati in maniera sicura per un periodo non inferiore ai sei mesi e deve essere consultabile dall’azienda e dalle autorità.
I log in dettaglio
Analizziamo ora in dettaglio le modalità operative di raccolta e conservazione dei log, specificando in particolare quali tipi di dati devono essere registrati, le modalità di registrazione, quelle di conservazione ed infine le modalità di accesso ai dati.
Relativamente alle tipologie di informazioni registrate nei log degli apparati che compongono il sistema (apparati server, apparati di rete, piattaforme applicative, apparati per la sicurezza perimetrale) è necessario premettere quanto sia indispensabile, per una corretta tracciatura delle informazioni, che tutti gli utenti debbano collegarsi ai sistemi informativi utilizzando esclusivamente account personali e che l’orario interno dei sistemi debba essere sincronizzato con i già citati time server di Stratum 0 predisposti a tale scopo tramite protocollo NTP (Network Time Protocol).
Sui sistemi server devono essere monitorati tutti gli accessi (access log), locali o via rete, degli utenti. In particolare deve essere garantita la registrazione dei seguenti dati:
- orario dell’evento;
- host di provenienza (IP/nome macchina);
- utente (userlD) che effettua o tenta di effettuare l’accesso;
- tipologia ed esito dell’evento (login, logout, accessi falliti, interrogazione di un database ecc.).
Sugli apparati per la registrazione degli eventi di sicurezza (firewall, IPS/IDS) devono essere registrati almeno i seguenti dati:
- orario dell’evento;
- tipologia dell’evento;
- indirizzo IP o host sorgente;
- indirizzo IP o host di destinazione, se presente.
Per garantire la disponibilità dei log anche in caso di malfunzionamento, i dati generati devono essere raccolti e conservati su una piattaforma terza e la registrazione dei dati deve essere effettuata garantendone le caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità.
L’accesso ai dati presenti sul sistema di conservazione deve essere consentito solo agli operatori autorizzati ed esclusivamente per le operazioni strettamente legate con il loro incarico (troubleshooting, controllo attività).
Log management: protezione dei dati raccolti
Gli amministratori del sistema centralizzato non possono svolgere attività amministrative sui sistemi sorgente oggetto di raccolta dei file di log (applicazione del principio di separation of duties).
Seguendo le regole dettate dalle best practices di sicurezza e dagli standard Internazionali (ISO 27001) gli apparati che fanno parte del sistema centralizzato per raccolta, analisi e archiviazione dei file di log dovrebbero essere posizionati all’interno di un’area ad accesso fisico controllato.
L’accesso logico al sistema centralizzato da parte di utenti con privilegi elevati (per esempio modifica/cancellazione di eventi e/o file di log) dovrebbe avvenire tramite autenticazione forte.
L’accesso ai file di log deve essere regolamentato per tutto il ciclo di vita del sistema informativo, indicando con granularità i profili delle utenze che possono accedere e con quali privilegi. La definizione dei profili di accesso ai log deve rispettare il principio del need to know. A tale scopo, i profili assegnati agli utenti devono consentire a questi lo svolgimento delle sole attività coerenti con i rispettivi ruoli svolti. L’accesso ai file di log deve essere regolato sulla base di un processo formale, avviato dalla Funzione che ne richiede l’utilizzo per lo svolgimento degli obiettivi assegnati.
I report in un sistema di log management
È sempre consigliato predisporre un’adeguata reportistica che si compone di report periodici sviluppati in base alle esigenze dei servizi svolti e di report “estemporanei” che possono essere prodotti solitamente su richiesta di enti esterni quali l’autorità giudiziaria o il Garante della privacy, oppure per rispondere a processi di audit interni.
Dal SIM al SIEM: come evolvono i sistemi di log management
Come visto precedentemente, abbiamo varie esigenze che ci spingono ad adottare sistemi di gestione dei log. La compliance alla normativa, assieme alla necessità di monitorare gli accessi eseguiti da utenze con diritti elevati sui nostri sistemi, approdano all’implementazione del già citato SIM (Security Information Management).
Altro fattore importante da considerare è l’aspetto più puramente gestionale che comprende i processi legati ai principi ITIL (Information Technology Infrastructure Library).
La necessità di analizzare in tempo reale eventi provenienti dai nostri sistemi di sicurezza, dagli apparati di rete e da tutte le altre componenti dell’infrastruttura (sistemi operativi, database, storage e applicazioni complesse), al fine di fornire un monitoraggio della sicurezza, correlazione degli eventi e risposta agli incident ed ai problem (definizioni squisitamente ITIL), ci porta necessariamente alla creazione di un sistema che possiamo definire SEM (Security Event Management).
In questo modo è possibile avere il massimo supporto per la gestione delle minacce (sia interne che esterne) che insistono sulla nostra realtà e, nel contempo, accresce la capacità di individuare e gestire gli incidenti informatici a cui inevitabilmente i nostri sistemi sono soggetti, aprendo anche la possibilità di supportare eventuali analisi forensi.
A questo punto il passo è breve.
La fusione, in senso lato, delle due funzionalità descritte sopra porta alla nascita del SIEM (Security Information and Event Management). L’adozione di questo tipo di sistemi consente di mettere in campo una capacità di elaborazione di eventi provenienti da sorgenti differenti, incrociandoli al fine di dedurre ad esempio informazioni relative a possibili attacchi a cui è sottoposta l’infrastruttura.
Con le stesse modalità dei due sistemi da cui deriva, un buon SIEM deve comprendere le seguenti funzionalità e caratteristiche:
- Collezionamento dei log: il sistema deve provvedere alla raccolta centralizzata delle informazioni provenienti dalle diverse sorgenti, prevedendo eventualmente storage separati per ogni tipologia, Ciò comporta inevitabilmente il dover supportare diversi formati di log. Altro aspetto fondamentale è la possibilità di supportare temporanei disservizi dello storage centralizzato continuando a raccogliere informazioni (mantenute in locale nei vari sottosistemi);
- Analisi dei log (in tempo reale): è richiesta al sistema una capacità di normalizzazione dei dati, funzionale alla loro successiva aggregazione. Questo, unito alla possibilità di effettuare analisi sullo storico dei log raccolti crea il valore aggiunto della soluzione (ed apre altri scenari quali il machine learning). A corredo di queste operazioni il sistema deve essere in grado di fornire l’adeguata reportistica;
- Conservazione dei log: al fine di mantenere le funzionalità di compliance il sistema deve comunque garantire l’inalterabilità dei log e la possibilità di verifica dell’integrità di questi ultimi. Tutte le soluzioni attualmente sul mercato permettono di salvare i log allo stato originale (log RAW) e di crittografare i file durante la conservazione per rispettare i principi di riservatezza.
Conclusioni
Un sistema con tali caratteristiche è senz’altro poco economico (per la gioia dei responsabili degli acquisti in azienda), ma un bravo responsabile della sicurezza, per perorare la sua causa, può portare a suo favore per supportare la necessità dell’azienda di dotarsi di un tale strumento, i dati pubblicati nell’ultimo rapporto FireEye relativo all’andamento delle minacce informatiche avvenute worldwide nel 2017. I report mettono in evidenza quanto la ancora poca sensibilità verso l’analisi degli eventi che insistono sulle infrastrutture porti a non riuscire ad intercettare le numerose azioni malevole sia esterne che interne.
Dwell time rappresenta il numero di giorni trascorsi dalla prima evidenza di compromissione del Sistema da part di un attaccante rispetto alla data di rilevazione dell’attacco stesso da parte della vittima.
La notizia positiva è rappresentata però dal fatto che i tempi di rilevazione hanno un trend decrescente negli ultimi anni come indicato nel report seguente, segno che almeno gli investimenti iniziano ad andare nella “giusta” direzione.
Il report indica che i tempi di rilevazione delle minacce informatiche hanno un trend decrescente negli ultimi anni.
Secondo uno studio dell’agenzia Market&Market il mercato dei servizi di log management dovrebbe aumentare da 707 milioni di dollari nel 2017 a 1.248,9 milioni di dollari entro il 2022, con un tasso di crescita annuo composto (CAGR) del 12,1%. L’anno base per lo studio è stato il 2016 e il mercato è calcolato dal 2017 al 2022.
