I modelli dei log di sicurezza: Syslog e SIEM
Il modello Syslog
In una infrastruttura di log management (gestione dei log) basata sul modello syslog, ogni sorgente produce log dello stesso formato e utilizza lo stesso meccanismo per trasferire i log a un server syslog remoto. Syslog fornisce un semplice framework per la generazione, lo storage e il trasferimento dei log, che ogni sistema operativo, software di sicurezza o applicazione può utilizzare, se è progettato per poterlo fare. Molte sorgenti di log usano syslog come formato nativo oppure offrono la possibilità di convertire i log dal loro formato nativo a syslog.
Lo standard syslog consente di operare una classificazione del messaggio, al fine di di stabilirne la tipologia e la priorità, basandosi su due attributi: la facility e la severity. La facility rappresenta la tipologia del messaggio, per esempio messaggio del kernel, messaggio di autorizzazione, di sicurezza, applicativo. La severity può assumere un valore compreso fra 0 (emergency) e 7 (debug).
Il formato syslog è pensato per essere molto semplice e prevede che ogni messaggio sia formato da 3 parti: la prima parte contiene la facility e la severity, descritte sopra, in formato numerico, la seconda parte contiene il timestamp e il nome host (o l’indirizzo IP) del sistema che ha generato l’evento e la terza parte è il contenuto del messaggio. Non ci sono campi standard definiti per syslog e l’unica possibilità di classificazione è quella basata su severity e faciltiy: solo mediante questi attributi è possibile decidere come trattare e come fare il forward dei log.
Lo storage dei log syslog può essere effettuato utilizzando file di testo locali al sistema che li ha generati oppure può essere effettuando un forward verso uno o più sistemi centralizzati.
Lo standard syslog è stato progettato in tempi in cui la sicurezza dei log non era oggetto di molta considerazione, per cui presenta alcuni aspetti critici. In primo luogo il protocollo di trasporto utilizzato da syslog per la trasmissione sulla rete è l’UDP, protocollo senza connessione che non garantisce la consegna dei pacchetti. In secondo luogo, il server syslog che raccoglie messaggi via rete non effettua nessuna forma di autenticazione, per cui qualsiasi sistema può inviare messaggi al server syslog, senza nessun ulteriore controllo. In terzo luogo, i log trasmessi via rete da syslog viaggiano in chiaro ed è quindi possibile intercettarli. Alcune implementazioni di syslog presentano soluzioni a uno o più di questi problemi, per esempio utilizzando TCP invece che UDP, utilizzando TLS per crittografare i dati sulla rete e così via, basate su una proposta di standard l’RFC 3195, che ha lo scopo di migliorare la sicurezza di syslog, oppure anche soluzioni non previste dall’RFC 3195, come la memorizzazione dei log su database. Queste implementazioni, tuttavia, non sono supportate da tutti i sistemi.
Il modello SIEM
Il modello System Information and Event Management (SIEM), pur non essendo standardizzato prevede maggiori funzionalità rispetto al modello syslog e prevede un’infrastruttura più complicata, contenente uno o più server che permettono l’analisi dei log, un database, strumenti per la correlazione degli eventi, uno o più database server per lo storage dei log, strumenti sofisticati per la ricerca e la reportistica. Per approfondire l’architettura del modello SIEM si legga il seguente articolo.
