Architettura del modello SIEM (log di sicurezza)

Architettura del modello SIEM (log di sicurezza)

Sebbene non esista uno standard che definisca l’architettura del modello SIEM, è tuttavia possibile descrivere i moduli di cui solitamente si compone e le loro interazioni.

Possiamo dunque distinguere cinque moduli: generazione di eventi, collezionamento di eventi, registrazione e immagazzinamento, analisi, monitoraggio e reporting. Nel seguito dell’articolo approfondiremo le funzioni di ognuno di questi moduli, unitamente ad una discussione sulle problematiche da affrontare e le possibili soluzioni. Verranno anche discusse le modalità di integrazione fra i diversi moduli.

Architettura  di un SIEM - Macro architettura di un SIEM
Architettura di un SIEM Macro architettura di un SIEM

Generazione di eventi

La generazione degli eventi avviene all’interno dei sistemi e delle applicazioni di cui si vogliono raccogliere i log da far pervenire al SIEM. Ad una prima analisi questo modulo sembrerebbe non fare parte del modello SIEM, tuttavia, considerando il SIEM come un processo piuttosto che come un sistema da acquistare ed installare, anche questo modulo rientra a tutti gli effetti nel SIEM.

Possono essere considerate due diverse famiglie di eventi generati. I generatori di dati basati su eventi (sensori), generano eventi corrispondenti a specifiche operazioni svolte da sistemi operativi, applicazioni, dispositivi di sicurezza e così via sulla rete. I generatori di dati basati sullo stato (poller), generano eventi basati sulla reazione a stimoli esterni, come un ping, dati relativi a check di integrità o demoni che hanno il compito di verificare lo stato di un certo servizio.

  • Sensori. Sebbene nell’ambito della sicurezza informatica il tipo più noto di sensori siano gli IDS, sia network based che host based, si possono far rientrare in questa categoria la maggior parte delle tipologie di log di sicurezza, come i log di firewall, VPN, sistemi di autenticazione, i log di sistemi operativi e applicazioni, ecc.
  • Poller. Lo scopo dei poller è quello di generare un evento ogni qualvolta un sistema terzo raggiunga un determinato stato. In un ambito di sicurezza, i poller sono responsabili della verifica dello stato di servizi (per rilevare la presenza di DOS) e la verifica dell’integrità.

Collezionamento

Lo scopo di questo modulo è quello di raccogliere informazioni dai diversi sensori e poller e tradurle in un formato standard, in modo da avere una base omogenea di messaggi.

Al di là dei diversi meccanismi di collezionamento utilizzati dal modello SIEM, esistono fondamentalmente due metodi di collezionamento. Si parla di metodo basato su agenti (agent-based ) quando il collezionamento avviene attraverso un agente software del SIEM installato sul sistema sorgente, di metodo senza agenti (agentless), quando il collezionamento avviene senza nessun tipo di agente installato su di esso.

  • Agentless. Il server SIEM riceve i log dai sistemi sorgenti senza bisogno di installare su di essi nessun software particolare. Alcuni SIEM hanno la possibilità di iniziare la connessione con il sistema sorgente, utilizzando opportuni meccanismi di autenticazione, e andare a reperire ad intervalli regolari i log presenti, per esempio disponibili in un database o in un file di testo; si parla in tal caso di metodo pull. In altri casi i sistemi sorgente inviano loro stessi i log al SIEM, dove è presente un opportuno receiver: in tal caso si parla di metodo push. Esempio di questo tipo di metodo è il syslog.
  • Agent based. Un agente software è installato sui sistemi che generano i log, allo scopo di effettuare filtraggio, aggregazione e normalizzazione per un certo tipo di log, trasmettendo poi i dati dei log normalizzati, normalmente in real-time o quasi in real-time, per l’analisi e l’immagazzinamento. Se un sistema ha diverse tipologie di log di interesse, è necessario installare più agenti.

In ognuna delle precedenti tipologie di collezionamento sono presenti vantaggi e svantaggi. Il vantaggio principale dell’approccio agentless è che non occorre installare, configurare e mantenere agenti in ogni sorgente di log. Lo svantaggio principale sta invece nel fatto che non è possibile effettuare filtraggio, aggregazione e normalizzazione a livello di sistema sorgente. Un altro possibile svantaggio è nella necessità di dotare il SIEM di credenziali valide per ogni sistema sorgente.

Normalmente i SIEM hanno metodi predefiniti per il collezionamento, il filtraggio, l’aggregazione e la normalizzazione di log di particolari sistemi o applicazioni (per esempio, server web, database relazionali, mail server, ecc.). In tali casi il SIEM sa come interpretare i vari campi presenti nel log originario (per esempio il campo numero 12 rappresenta l’IP sorgente) o determinati valori presenti nel log originario (per esempio l’evento con codice 680 in un sistema Windows  rappresenta  un’autenticazione fallita).

Per sistemi o applicazioni che non dispongono di metodi predefiniti i SIEM forniscono normalmente strumenti che permettono di costruirsi i propri metodi, rendendo il SIEM molto più flessibile. Naturalmente per costruire il proprio metodo di collezionamento è indispensabile conoscere il formato dei log da collezionare e dei campi disponibili all’interno del SIEM.

Scopo del modulo di collezionamento è anche quello di operare una normalizzazione dei log. Con normalizzazione si intende il processo che permette di trasformare i log raccolti dai diversi sistemi sorgenti nei loro formati nativi in un unico formato che sia utilizzabile all’interno del SIEM.

Altre operazioni che possono avvenire nell’ambito di questo modulo sono il filtraggio e l’aggregazione. Con filtraggio si intende la selezione, all’interno del sistema sorgente, dei log che hanno un certo interesse per la successiva registrazione e analisi e l’esclusione dei log privi di interesse. Con aggregazione si intende il consolidamento di più eventi simili in un’unica entry che abbia un campo contatore del numero di eventi.

Registrazione e immagazzinamento

Per lavorare con l’elevato numero di log che arrivano al SIEM, occorre definire un sistema di memorizzazione che permetta di conservare i log per il periodo definito allo scopo di soddisfare i requisiti normativi e di effettuare analisi storiche. Nella scelta del meccanismo di memorizzazione occorre tenere presente la facilità con cui è possibile definire query per estrarre gli eventi di interesse e la rapidità di risposta alle query definite.

Esistono tipicamente tre metodi di memorizzazione dei log: in un database, in file di testo, in file binari. Il caso di memorizzazione in un database standard è attualmente il più utilizzato, in quanto è il sistema che permette solitamente il miglior compromesso fra la necessità di utilizzare i log da parte di altre applicazioni, la necessità di eseguire facilmente le analisi, e la necessità di accedere a tali dati in maniera efficiente. I file di testo, pur permettendo l’accesso ai log da parte di altre applicazioni e di eseguire facilmente analisi, non permettono di accedere in maniera efficiente ai dati, soprattutto in presenza di archivi contenenti grandi quantità di log. Al contrario, i formati binari permettono di accedere in maniera efficiente ai dati, ma non permettono l’accesso ad altre applicazioni che non siano il SIEM stesso.

Per garantire l’integrità dei dati memorizzati, alcuni SIEM calcolano un digest sul database dei log, o sui file che contengono i log, o su ogni record contenuto nel database. Un digest è una firma che identifica univocamente i dati, con la caratteristica che cambiando un singolo bit del dato, il digest cambia. I principali algoritmi utilizzati per il calcolo del digest sono l’MD5 e lo SHA-1. In questa maniera, se per qualche motivo i log fossero alterati il digest cambierebbe e si avrebbe la prova dell’alterazione. Un altro meccanismo per garantire l’integrità può essere la conservazione dei log su dispositivi di sola lettura.

Pur nella specificità dei vari SIEM, per ognuno dei quali la tabella dei messaggi conterrà campi diversi, è possibile individuare un insieme minimo di campi che generalmente, affinché il SIEM possa svolgere la sua funzione, fanno parte della tabella dei messaggi.

  • Time. Contiene il timestamp in cui è avvenuto l’evento. Può essere affiancato da altri timestamp, per esempio il timestamp in cui è avvenuto il parsing dell’evento.
  • Type. Contiene il tipo di sistema che ha generato l’evento, per esempio sistema operativo, database, firewall, ecc.
  • Category. Contiene la tipologia dell’evento, per esempio se si tratta di un’autenticazione, di un’autorizzazione, dell’avvio di un’applicazione, ecc.
  • Severity. Contiene il livello di pericolosità dell’evento.
  • Device. Contiene il sistema che ha generato l’evento. Può essere diviso su più campi, contenenti per esempio l’indirizzo IP, l’hostname e il fully qualified hostname.
  • Source. Contiene il sistema da cui è partito l’evento. Per esempio, in un login via rete, contiene un riferimento al sistema da cui l’utente ha fatto il login. Come per il device, anche in questo caso l’informazione può essere divisa su più campi.
  • Destination. Contiene il destinatario dell’evento. Per esempio, in un login via rete, contiene un riferimento al sistema su cui l’utente ha fatto il login. Come per il device e il source, anche in questo caso l’informazione può essere divisa su più campi.
  • User. Contiene, se esiste, l’account che ha generato l’evento. Può essere diviso in user sorgente e user destinazione per tenere conto del caso di eventi che contengano una sorgente e una destinazione.
  • Message. Contiene un testo che descrive l’evento.

Oltre ai log, il SIEM si occuperà di registrare le statistiche e gli eventi di alert.

Analisi

Il Rule e il Correlation  Engine

Lo scopo dell’analisi è quello di cercare eventuali anomalie all’interno dei log, per esempio per rilevare attacchi o tentativi di attacco.  In un SIEM nel quale tutti i log con una qualche rilevanza dal punto di vista della sicurezza siano centralizzati e nel quale siano presenti strumenti che permettano di operare facilmente delle ricerche per individuare eventi di interesse, tale analisi può essere operata da parte di analisti della sicurezza; questo tipo di approccio, tuttavia, è utile soprattutto in fase investigativa. Per poter operare in maniera proattiva nei SIEM esiste normalmente un componente, il rule engine, che permette di generare allarmi da mostrare sulla console agli operatori del SOC, oppure da inviare via mail, in base al verificarsi di determinate condizioni. Generalmente le regole vengono scritte utilizzando una qualche forma di logica booleana.

Uno strumento più sofisticato per generare allarmi è rappresentato dal correlation engine, un sottoinsieme del rule engine che permette di correlare diversi eventi provenienti da diverse sorgenti creando un unico evento correlato. Tale correlazione viene operata allo scopo di semplificare l’identificazione di potenziali incidenti e le procedure di risposta.

La Knowledge Base

Di ausilio alla fase di analisi è anche la componente di Knowledge Base, dove viene tenuta traccia del livello globale di sicurezza dell’infrastruttura IT. Questo permette di valutare se un tentativo di intrusione su un certo sistema può effettivamente portare ad un’intrusione e il livello di criticità di tale tentativo di intrusione.

Fanno parte della componente di knowledge base il database degli asset, il database delle vulnerabilità e le policy di sicurezza dell’organizzazione.

Il database degli asset può essere utilizzato per definire alcuni aspetti delle configurazioni dei sistemi, il tipo di servizio garantito all’interno del sistema informativo, gli altri sistemi al quale sono correlati, i referenti; in definitiva lo scopo è quello di determinare il livello di criticità dei sistemi e l’impatto che può avere un’eventuale intrusione.

Il database delle vulnerabilità contiene informazioni relative alle violazioni della sicurezza e ai comportamenti insicuri che possono avere impatto sul livello globale di sicurezza o che possono essere utilizzate da un attaccante allo scopo di effettuare un’intrusione. Il database delle vulnerabilità può contenere i seguenti tipi di vulnerabilità:

  • vulnerabilità strutturali, ovvero vulnerabilità presenti in software specifici, per esempio buffer overflow; questa parte del database può essere popolata attraverso report di software di vulnerability scanner;
  • vulnerabilità funzionali, ovvero vulnerabilità che dipendono da configurazioni, comportamenti degli utenti, ecc. Un esempio di questo tipo è la presenza di un server nfs che espone delle share non adeguatamente protette di cui un eventuale malintenzionato può fare il mount, accedendo così al filesystem. Contrariamente alle vulnerabilità del tipo precedente, queste vulnerabilità dipendono fortemente dall’ambiente in cui La parte più difficoltosa è trovare il modo per definire / formattare questo tipo di vulnerabilità in maniera tale da popolare il database;
  • vulnerabilità basate sulla topologia di rete, incluso l’impatto delle intrusioni sulla rete e le loro conseguenze. Questa parte del database include le vulnerabilità di rete (sniffing, spoofing, ecc.) così come l’impatto del filtraggio sui path di intrusione. Questo tipo di vulnerabilità non possono essere contenute in un database, a meno che questo non supporti un minimo di modellazione topologica.

Gli aspetti principali delle policy di sicurezza che devono essere considerati sono le autorizzazioni e le procedure di testing /auditing. Questi due aspetti forniranno informazioni riguardanti i comportamenti che i sensori dovranno rilevare. Gli eventi generati (login amministrativi, portscan, ecc.) potranno essere marcati come conformi alle policy di sicurezza oppure come parte di un possibile tentativo di intrusione.

L’obiettivo finale della knowledge base è quella di valutare lo stato di sicurezza dei sistemi monitorati. Le informazioni contenute nella knowledge base possono essere processate da un apposito engine, che fornirà una lista delle vulnerabilità a cui ogni sistema è soggetto, il potenziale impatto di ogni vulnerabilità e i path di intrusione che possono sfruttare tali vulnerabilità. Tale valutazione andrà rigenerata ogni qualvolta venga trovata una nuova vulnerabilità e ogni qualvolta ci siano modifiche ai sistemi monitorati.

Monitoraggio

Il monitoraggio è il modo con cui gli operatori del SOC e gli analisti della sicurezza interagiscono con il log registrati nel SIEM.

Generalmente i SIEM hanno una console, che può essere web-based o clientserver, che permette di interagire con i dati registrati sul SIEM. In generale sono presenti tre interfacce:

  • interfaccia per il monitoraggio real-time: fornisce una visione real-time degli eventi che arrivano al SIEM, permettendo un filtraggio base allo scopo di isolare i messaggi di Viene usata per scopi di debugging, per analisi approfondite di eventi specifici e per la reazione ad eventi;
  • interfaccia per la gestione degli incidenti: è l’engine utilizzato per la creazione e la gestione di ticket di incidente e le procedure di reazione e risoluzione;
  • interfaccia per le analisi statistiche: fornisce dati sulle statistiche di attività di sicurezza sul corto, medio e lungo periodo.

Oltre alla console, i SIEM hanno generalmente strumenti meno operativi, a disposizione dei responsabili della sicurezza e del management aziendale. In generale sono presenti le seguenti interfacce:

  • interfaccia per la valutazione dei rischi: fornisce informazioni sull’attuale livello di sicurezza delle configurazioni dei sistemi monitorati e dei software Fornisce informazioni sul livello di sicurezza globale, sulle vulnerabilità e le criticità, gli scenari di intrusioni e i dettagli sulle patch e le configurazioni;
  • attività di sicurezza: fornisce reportistiche a medio e lungo termine sulle intrusioni verificatisi, tipi, frequenze, sorgenti e conseguenze sui sistemi monitorati. È usato per determinare trend, attacchi ricorrenti e sistemi maggiormente colpiti;
  • stato dei sistemi: fornisce un quadro sugli incidenti aperti, sistemi sotto attacco e path di intrusione attivati dagli attaccanti. Fornisce informazioni sulle procedure di reazione ed escalation messe in atto allo scopo di circoscrivere l’attacco.

 

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *