~/docs/SIEM.log

Prefazione

SIEM è l’acronimo inglese di Security Information and Event Management ed ha lo scopo di collezionare, analizzare, correlare e visualizzare tutti gli eventi di sistema generati dalle varie piattaforme installate nel nostro parco macchine.
Inoltre il SIEM aiuta a chi si occupa di sicurezza a mettere in evidenza gli ambiti nei quali è necessario intervenire attraverso una logica di interventi correttivi o migliorativi.

Le due “anime” sono il SIM (Security Information Management) e il SEM (Security Event Management) dove il primo si occupa dell’orchestrazione dei log mediante agent installati sui avari sistemi; il secondo – il SEM – provvede al monitoraggio e alla gestione degli eventi che accadono all’interno della rete e sui vari sistemi di sicurezza andando a correlare e aggregare i dati ricevuti.

I log collezionabili possono essere di varia natura, ad esempio:

1. Strumenti di sicurezza tipo IDS, IPS, AV/AM, firewall, etc
2. Dispositivi di rete quali router, switch, DNS server, W.A.P., etc
3. Dispositivi quali PC client, server Windows o Linux, Mac, etc
4. Applicazioni intranet, web, SaaS, etc
5. Altro

Come si evince dalle fonti “monitorabili”, il principio è un monitoraggio basato sulla capacità di aggregare dati eterogenei, provenienti da molteplici fonti, stabilendo in tempo reale le correlazioni finalizzate a individuare comportamenti anomali, generare allarmi, rispondendo alle esigenze di incident response, compliance e analisi forensi.

L’analisi, cioè da dove cominciare

Sebbene nell’era dei log 4.0 l’implementazione di un SIEM risulta essere più facile e veloce rispetto agli anni passati è indispensabile rispondere a queste quattro domande onde evitare di “affogare” nel mare delle segnalazioni.

1. Stabilire cosa si vuole monitorare, cioè definire quali sono gli obiettivi: monitorare TUTTO non è MAI una buona idea, specialmente se gestite infrastrutture vaste e complesse (credetemi, esperienza personale!)
2. Gestione dei log, cioè identificare quali sono le fonti che alimentano i miei obiettivi
3. Le correlazioni e la gestione dei pesi (o severity): punto fondamentale. Cosa si deve correlare? Quali sono i “trigger” che fanno scattare gli allarmi? Quali sono gli alert che hanno maggior peso rispetto ad altri?
4. Gestione dell’alert e il monitoraggio, cioè come intervengo quando un allarme viene generato e cosa è meglio monitorare

Sebbene i punti 1,2 e 4 sono facili da comprendere, il punto 3 – la correlazione – è ovviamente il più complesso da gestire.

Un esempio

In un’ottica dove lo scopo dell’implementazione di un SIEM sia quello di controllare quello che succede nella propria infrastruttura in modo da cogliere i segnali di possibili incidenti/attacchi (punto 1), andando a monitorare gli eventi di sistema dei server coinvolti (es: A.D. – punto 2), i trigger potrebbero essere (ovviamente la lista non è esaustiva):

• SEVERITY: ALTO. Molteplici login falliti in un arco di tempo molto breve (es: 5 ogni 10 secondi)
• SEVERITY: CRITICO. Molteplici login falliti seguiti da uno andato a buon fine
• SEVERITY: MEDIO. Generazione di processi con utente differente da quello attualmente loggato
• SEVERITY: MEDIO. Tentativo di lettura o lettura implicita degli hash presenti sulla macchina
• etc

Se a questa semplice infrastruttura di esempio aggiungessimo un firewall a monte per gestire le connessioni SSLVPN, allora si potrebbero aggiungere altri trigger quali:

• SEVERITY: BASSO. Molteplici tentativi di collegamento SSLVPN dallo stesso IP (pro tip: magari anche con gestione del geoip di modo da identificare e se la connessione proviene da un paese dove non ho sedi e/o dipendenti)
• SEVERITY: ALTO. Molteplici login falliti seguiti da uno andato a buon fine
• etc

Seguendo il nostro esempio, le ovvie correlazioni potrebbero essere:

1. un possibile attaccante tenta un attacco brute force al firewall con lo scopo di indovinare le credenziali di un utente attivando il trigger a valore basso ma senza che nessun operatore del SOC venga avvisato
2. la segnalazione passa a livello alto quando lo stesso IP riesce a loggarsi. Scatta pertanto il trigger legato ai log dei firewall e l’operatore del SOC riceve una segnalazione via mail
3. l’utente malevolo, ora collegato alla VPN, inizia un attacco brute-force verso il server dell’Active Directory aumentando ulteriormente il peso della segnalazione
4. L’Active Directory produce un altro log indipendente da quello del firewall a severity alta il quale viene correlato, mediante l’IP sorgente rilasciato dall’SSLVPN, all’attaccante che ha fatto generare precedentemente l’allarme sul firewall. A questo punto la segnalazione passa a livello “critico”.

Per concludere, il l’operatore del SOC attua le policy di remediation quali:

• blocco tempestivo del tunnel SSLVPN
• ban dell’IP sorgente
• cambio password e/o bonifica dell’utente hackerato
• implementazione di una nuova dashboard per il monitoraggio delle login fallite sul firewall (punto 4)

Qualche considerazione personale

La prima: che sia gestito “in casa” o acquistato come servizio da una società specializzata, il SIEM è a mio avviso fondamentale. Questo perché risolve non solo quella quota parte di possibili tentativi di attacco, ma anche – e soprattutto – perché mette in luce le anomalie di configurazione che inevitabilmente si vanno a creare per distrazione o per mal configurazione.

Un’esempio, questa volta reale, ve lo riporto dalla mia esperienza.

Avevo appena messo in piedi il mio SIEM e ricevevo dall’A.D. qualcosa come 700.000 tentativi di autenticazione falliti al giorno con l’utente “Administrator” di dominio. Inutile dire che, in una situazione sotto controllo, questo evento sarebbe da considerare critico ma, andando a controllare quale servizio andava ad eseguire tutte quelle login fallite, mi sono accorto che il processo che gestiva il SSO del firewall – mediante secure LDAP – era stato configurato con l’utente “Administrator” di dominio (primo errore) e, a causa di un cambio password, questo falliva l’autenticazione (il numero ingente era dettato dalla policy di DPI la quale controlla tutte le connessioni senza fare caching).

Ma non solo: tutte quelle scritture da parte dell’Event Viewer di sistema andavano a “picchiare duro” (non ricordo quanti IOPS facesse ma erano davvero tanti!) sullo storage con il risultato che, sebbene la macchina non soffrisse né di RAM né di CPU, questa era rallentata con conseguenti problematiche a tutti gli altri servizi (DNS, repliche, autenticazioni, etc).

Cambiato l’utente con uno senza privilegi ed impostato con una password corretta, il servizio SSO ritornò a funzionare correttamente con tempi di risposta nella norma.

La seconda considerazione che vorrei fare è questa: fare correlazione è complesso, richiede tempo e tanta esperienza. Se non siete sufficientemente skillati sull’argomento non improvvisatevi. Piuttosto chiedete aiuto a società esterna che magari integri anche il servizio con un SOC h24.
Ricordatevi che non non c’è nulla di male a chiedere aiuto e soprattutto passerete notti più tranquille sapendo che la vostra infrastruttura è coperta!

La terza e ultima considerazione invece va fatta sulle azioni di remediation.
Il SIEM non è uno strumento di orchestrazione automatica di risposta a fronte di un incidente (e forse è meglio così)!

Provate ad immaginare se un client in una vostra sede remota iniziasse a fare traffico verso un IP pubblico sconosciuto in HTTPS, poi un secondo client stesso comportamento, seguito da un terzo e via dicendo: che fare? E’ traffico consentito o i client stanno comunicando con un C2? Se è traffico consentito cos’è? Un backup offsite? Come lo identifico? Anche avendo l’SSL inspection attivo sul firewall ho tempo per sniffare il traffico prodotto e decriptarlo?
Quindi? Isolo la sede o isolo i client? E se la sede è un’impianto di produzione? Blocco la produzione per del traffico HTTPS che non so cosa sia?

Questa è solo una minima parte delle domande che ci si potrebbero porre e – come è facile intuire – non è facile avere risposte certe. Pertanto vien da se che creare regole di remediation automatiche è pressoché impossibile se non per specifiche realtà circoscritte e ben definite.

Concludendo:

1. Vale la pena implementare un SIEM? Si, ma solo se si hanno le capacità tecniche per gestirlo. Se non siete in grado o non avete risorse a sufficienza rivolgetevi alle aziende che lo fanno di mestiere.
2. Con un SIEM sono sicuro al 100% che la mia infrastruttura sia sicura? No, ovviamente. La sicurezza al 100% è impossibile (e chi ve la vende mente sapendo di mentire) ma, se ben gestito, vi garantirà una governance più efficace e dettagliata dei vostri sistemi
3. Come faccio a capire se un evento è un falso positivo o un vero attacco? Analizzando a fondo la vostra infrastruttura. Un buon punto di inizio (o per meglio dire “è il punto di inizio”) è quello di eseguire un assessment sulla postura, a tal proposito ho scritto un post.

EOF