ABC della sicurezza: SIEM, Security Information and Event Management

Tre indizi fanno una prova?

“Se sembra un’anatra, nuota come un’anatra e starnazza come un’anatra, allora probabilmente è un’anatra”, questo è quanto recita il noto test dell’anatra secondo cui è possibile identificare un soggetto attraverso i suoi comportamenti, per induzione e data la tipicità dei comportamenti stessi. Purtroppo nell’ambito della sicurezza informatica le anatre cercano di sembrare passeri, nuotano come pinguini e non starnazzano nemmeno. A Sherlock Holmes, maestro di abduzione, bastano pochi indizi per svelare il ritorno alla professione medica di Watson: “Se un distinto signore entra nella mia stanza odorando di iodoformio, con una macchia nera di nitrato d’argento sull’indice della mano destra, e un rigonfiamento sul lato destro del cilindro, dove ha nascosto lo stetoscopio, dovrei essere davvero ottuso se non lo riconoscessi come un membro attivo della classe medica.”, ma probabilmente nemmeno il virtuoso delle investigazioni uscito dalla penna di Sir Arthur Conan Doyle potrebbe averla vinta di fronte a migliaia e migliaia di eventi al secondo che gli scorrono davanti agli occhi.

È questo ciò di cui stiamo parlando e che avviene ogni giorno, ogni millisecondo, in ciascuna delle nostre aziende: accade un evento e questo evento lascia una traccia. Ma chi o che cosa riesce a vedere la “big picture” di ciò che sta accadendo per discernere un accadimento malevolo all’interno del magmatico rumore di fondo?

Che cos’è un SIEM

Che cosa si intende per SIEM? SIEM è l’acronimo di “Security Information and Event Management” e definisce un prodotto costituito da software e/o servizi che unisce capacità di “Security Information Management” (SIM) a quelle di “Security Event Management” (SEM), il termine è stato coniato da Amrit Williams e Mark Nicolett nel 2005, quando entrambi lavoravano per Gartner. In italiano possiamo tradurlo come “Sistema di Gestione delle Informazioni e degli eventi di Sicurezza”

Volendo sintetizzare il ruolo svolto dalle due componenti: un SIM si occupa della parte di “Log management”, di attività di analisi e della produzione di report per aderire a ad esempio norme di compliance. D’altro canto, un SEM si occupa del monitoraggio in real-time degli eventi, dell’incident management (in ambito security)  per quanto riguarda eventi che accadono sulla rete, sui dispositivi di sicurezza, sui sistemi  o le applicazioni.

In sostanza un SIEM mira a risolvere esigenze in ambito di gestione delle minacce informatiche ed in ambito regolatorio o di compliance. Non è infrequente che la spinta a rispondere ad esigenze regolatorie abbia agevolato l’introduzione dei SIEM nelle aziende che li hanno così potuti sfruttare anche per gli scopi di security e rilevazione delle violazioni (“breach detection”).

Un buon SIEM è, quindi, uno dei fondamentali strumenti per un approccio alla difesa in profondità a beneficio della sicurezza delle aziende.

Il mercato dei SIEM è cresciuto per una quota che varia, secondo le stime, fra l’11% e 12,5% nel corso del 2014 (http://www.gartner.com/newsroom/id/3062017)

I SIEM devono rispondere all’esigenza che è sorta nel corso degli anni di applicare in maniera sistematica un’analisi computazionale di dati o statistiche inerenti alla sicurezza informatica, quest’analisi deve avvenire in tempo reale in modo da rilevare in maniera tempestiva attacchi mirati e violazioni dei dati (“data breaches”), altra necessità che i SIEM devono soddisfare è quella di raccogliere, memorizzare, analizzare e rendere disponibile in forma di report i dati provenienti dai log per esigenze di incident response, di compliance in ambito regolatorio o per attività di analisi forense.

Le tecnologie SIEM aggregano dunque i dati corrispondenti agli eventi prodotti da dispositivi di sicurezza (firewall, IDS, IPS, ecc.), dalle infrastrutture di rete, da sistemi ed applicazioni. Come detto la fonte principale dei dati che vengono analizzati da un SIEM sono i log, tuttavia un SIEM non si limita a questo in quanto potrebbe essere in grado di elaborare dati sotto altre forme quali flussi Netflow o addirittura il vero e proprio traffico di rete. I dati “grezzi” devono poi essere contestualizzati ed in questo senso il SIEM deve essere in grado, dopo una fase di “normalizzazione” dei dati stessi, di correlare gli eventi provenienti dalle fonti più disparate calandoli nella “realtà” in cui sta operando che è fatta di utenti, asset, minacce e vulnerabilità dei sistemi. La fondamentale parte di correlazione, che rappresenta l’intelligenza del sistema, deve avvenire in tempo reale ed è l’arma fondamentale per chi si trova a gestire migliaia di eventi ed incidenti di sicurezza. La possibilità di effettuare query, di monitorare l’attività degli utenti e delle applicazioni, di effettuare report a scopo di audit o di compliance rappresentano poi altri fondamentali tasselli che compongono un’efficace soluzione SIEM.

Per fare alcuni esempi, le regole di correlazione possono servire ad individuare: possibili attacchi di tipo brute force, minacce dovute ad attacchi provenienti dall’interno (malicious insiders ovvero utenti interni all’organizzazione con intenti malevoli), oppure a tracciare sistemi infetti o compromessi da malware tramite l’analisi e l’incrocio dei dati provenienti dai log del traffico in uscita dal firewall, dai log del Web Proxy,  dagli allarmi dell’IPS, così come dai flussi di rete interni.

Oltre quanto descritto, una soluzione SIEM può anche fornire soluzioni di:

• Controllo dell’integrità dei file (FIM – File Integrity Monitoring)
• Configuration management database (CMDB )
• L’integrazione con “feed” di threat intelligence (reputation di IP e URL, information sharing quali STIX™/TAXII™)
• Vulnerability Assessment
• Configuration Assessment
• Asset discovery
• NIDS/HIDS
• Integrazione con Identity and Access Management (IAM)
• Incident Management e Ticketing, tracciatura di eventuali SLA, gestione dei Workflow in risposta ad un incidente
• Raccolta di dati provenienti dagli endpoint (log locali, integrità dei file, monitoraggio dei registri di Windows e dei processi di sistema)
• Definizione di una “baseline” dell’ecosistema e rilevazione delle eventuali deviazioni rispetto alle normali attività.
• L’analisi dei comportamenti degli utenti al fine di rilevare comportamenti sospetti (User Behavior Analysis – UBA)
• Network Forensics
• Gestione e profilazione del rischio
• “Replay” di eventi passati (la possibilità di “rivedere” una sequenza di eventi passati per verificarne cause ed effetti eventualmente malevoli)
• Integrazione con soluzioni di Malware Detection e Sandboxing

Come decidere

Le aziende, per orientarsi verso la scelta migliore, dovrebbero basarsi sulle proprie specifiche esigenze , sulla  maggior o minore propensione ad un utilizzo dello strumento in ambito compliance rispetto ad un utilizzo in ambito security.

Altri driver fondamentali per la scelta sono anche:

Il costo, che può essere commisurato al numero di appliance desiderati o necessari, al numero di eventi al secondo gestiti, alla quantità in GB analizzati in un giorno o al numero delle fonti da cui provengono i dati da analizzare

La modalità di deployment. La soluzione può essere costituita da un’appliance fisica, oppure da una software o viurtual appliance, ovvero da soluzioni SAAS/IAAS.

Il cliente deve inoltre chiedersi se preferisce una soluzione nella quale trova gran parte delle regole di correlazione già pronte, standard e predefinite oppure se predilige uno strumento che dia ampie garanzie di customizzazione delle regole. In generale, è necessario capire se si propende per una soluzione che sia il più possibile pronta “out-of-the-box” o la si vuole poter adattare in maniera “sartoriale” alle proprie esigenze perché si dispone internamente  delle risorse in termini di tempo/uomo e skill.

È poi fondamentale guardarsi allo specchio quali destinatari e utenti finali e considerare se, dal punto di vista ICT e della quantità di dati oggetto di analisi, ci si ritiene una piccola o una grande azienda, se si dispone di un SOC interno, se l’intento è quello di erogare servizi in qualità di MSSP, se si opera in ambito ICS (Industrial Control Systems) o SCADA (Supervisory Control And Data Acquisition), perché ciascuna di queste realtà ha esigenze e capacità differenti.

Altri fattori da tenere presenti sono l’integrazione ed eventuale sinergia con prodotti e tecnologie già presenti in azienda. E, come sempre, è da valutare anche il livello e la qualità del supporto che ci vengono garantite dal fornitore.

Per riordinare le idee faccio ricorso a questo interessante documento “2016 Security Information and Event Management Buyer’s Guide” secondo il quale, prima di scegliere e acquistare una soluzione SIEM, occorre porsi 5 domande e porne altrettante al vendor/fornitore che si sta valutando.

Ecco una breve sintesi di queste “domande guida”, le prime sono quelle da porsi internamente alla propria organizzazione:

1. Saremo in grado di gestire e governare la soluzione? Abbiamo le risorse interne per farlo?
2. Che cosa vuole ottenere esattamente la nostra azienda dalla soluzione?
3. Siamo certi di avere bisogno di una soluzione SIEM completa o è sufficiente una soluzione di semplice “log management”?
4. Quanto vogliamo spingerci nella “Security Analytics” (Big Data, algoritmi di analisi evoluti,…) rispetto ad una soluzione “tradizionale”?
5. Quanto intendiamo spendere?

Le altre 5 domande sono invece da porre al vendor/fornitore:

6. In che modo il vostro prodotto va incontro alle nostre esigenze di compliance in fatto di audit o in ambito regolatorio?
7. Offrite assistenza nel “deployment” della soluzione? È prevista da parte vostra una fase di training per il nostro personale?
8. Siete o sarete in grado di supportare le nostre esigenze, attuali o future, in ambito piattaforme “cloud” o in ambienti “Big Data”?
9. In che maniera il vostro SIEM gestisce le varie fonti di log? Vengono nella maggior parte supportate in maniera “nativa” o è necessaria una fase più o meno dispendiosa di customizzazione?
10. In che modo la vostra soluzione fornisce all’analista o alla squadra di analisti i risultati delle proprie attività? (Importante la parte di “data visualization” e le funzioni di ricerca all’interno dei log)

In sostanza è molto probabile che sul mercato si trovi la soluzione capace di soddisfare le esigenze di un’azienda; l’importante è però comprendere quali siano le reali finalità e quale sia il tecnologia più adatta a realizzarle. E come? Applicando saggiamente il cosiddetto “Rasoio di Occam” – mi perdoneranno i filosofi per l’interpretazione fin troppo estensiva del concetto –, facendo tesoro di questi due straordinari motti:

«Entia non sunt multiplicanda praeter necessitatem» (Non moltiplicare gli elementi più del necessario)
«Frustra fit per plura quod fieri potest per pauciora» (È inutile fare con più ciò che si può fare con meno).