I costi nascosti del SIEM gratuito

Secondo il rapporto “State of Open Source” di OpenLogic, il 96% delle organizzazioni intervistate utilizza soluzioni open source (OSS). Tali soluzioni sono disponibili in ogni segmento del mercato IT, inclusi gli strumenti di infosec. E sono spesso consigliati per la creazione di sistemi SIEM.

A prima vista, OSS sembra un’ottima scelta. La funzione primaria di un sistema SIEM è la raccolta e la correlazione sistematiche dei dati di telemetria, che è possibile impostare utilizzando noti strumenti di archiviazione ed elaborazione dei dati. È sufficiente raccogliere tutti i dati con Logstash, collegare Elasticsearch, creare le visualizzazioni necessarie in Kibana e il gioco è fatto! Una rapida ricerca consentirà di ottenere persino soluzioni SIEM open source pronte all’uso (spesso basate sugli stessi componenti). Con i SIEM, adattare sia la raccolta che l’elaborazione dei dati alle esigenze specifiche dell’organizzazione è sempre fondamentale e un sistema OSS personalizzato offre infinite possibilità in tal senso. Inoltre, il costo della licenza è zero. Il successo di questa impresa dipende tuttavia dal team di sviluppo, dalle specifiche dell’organizzazione, da quanto tempo è disposta ad attendere i risultati e da quanto è pronta a investire nel supporto continuo.

Il tempo è denaro

Una domanda chiave, la cui importanza è costantemente sottovalutata, è quanto tempo ci vorrà prima che il SIEM dell’azienda non solo diventi attivo, ma inizi effettivamente a fornire valore reale coerente. I dati di Gartner mostrano che anche un SIEM completo e pronto all’uso richiede in media sei mesi per l’implementazione completa, con un’azienda su dieci che ci dedica un anno. E se stai creando il tuo SIEM o adattando un OSS, dovresti aspettarti che questa sequenza temporale raddoppi o triplichi. Durante la definizione del budget, moltiplica tale tempo per le tariffe orarie degli sviluppatori. È anche difficile immaginare un SIEM a tutti gli effetti gestito da un singolo individuo di talento: l’azienda dovrà mantenere un intero team.

Una trappola comune è quella di essere fuorviati dalla velocità con cui un prototipo si assembla. È possibile distribuire un OSS già pronto in un ambiente di test in pochi giorni, ma portarlo alla qualità di produzione può richiedere molti mesi, persino anni.

Carenza di competenze

Un SIEM deve raccogliere, indicizzare e analizzare migliaia di eventi al secondo. La progettazione di un sistema ad alto carico, o addirittura l’adattamento di uno esistente, richiede competenze specialistiche e richieste. Oltre ai soli sviluppatori, il progetto avrebbe bisogno di amministratori IT altamente qualificati, ingegneri DevOps, analisti e persino progettisti di dashboard.

Un altro tipo di carenza che i creatori SIEM devono superare è la mancanza dell’esperienza pratica necessaria per scrivere regole di normalizzazione efficaci, logica di correlazione e altri contenuti predefiniti in soluzioni SIEM commerciali. Naturalmente, anche il contenuto pronto all’uso richiede modifiche sostanziali, ma è necessario adeguarlo agli standard dell’organizzazione in modo più rapido e semplice.

Conformità

Per molte aziende disporre di un sistema SIEM è un requisito normativo. Coloro che creano autonomamente un SIEM o implementano una soluzione OSS devono impegnarsi considerevolmente per ottenere la conformità. Devono mappare autonomamente le funzionalità del SIEM ai requisiti normativi, a differenza degli utenti dei sistemi commerciali, che spesso sono dotati di un processo di certificazione integrato e di tutti gli strumenti necessari per la conformità.

Talvolta, il reparto gestionale potrebbe voler implementare un SIEM solo per “spuntare una casella”, con l’obiettivo di ridurre al minimo la spesa. Ma poiché PCI DSS, GDPR e altri quadri normativi locali si concentrano sull’effettiva ampiezza e profondità dell’implementazione SIEM, non solo sulla sua mera esistenza, un sistema SIEM token implementato solo per fare spettacolo non supererebbe alcun controllo.

La conformità non è un aspetto che è possibile considerare solo al momento dell’implementazione. Se, durante l’esecuzione e la manutenzione autogestite, un componente della soluzione smettesse di ricevere aggiornamenti e raggiungesse la fine del suo ciclo di vita, le possibilità di superare un controllo di sicurezza precipiterebbero.

Confronto tra lock-in del fornitore e dipendenza dei dipendenti

Il secondo motivo più importante per cui le organizzazioni hanno preso in considerazione una soluzione open source è sempre stata la flessibilità nell’adattarla alle proprie esigenze specifiche, oltre a non fare affidamento sulla roadmap di sviluppo del fornitore di software e sulle decisioni in materia di licenze.

Entrambi sono argomenti convincenti e nelle grandi organizzazioni a volte possono prevalere su altri fattori. Tuttavia, è fondamentale fare questa scelta con una chiara comprensione dei pro e dei contro:

• I SIEM OSS possono essere più semplici da regolare per input di dati univoci.
• Con un OSS SIEM si mantiene il controllo completo sulle modalità di archiviazione ed elaborazione dei dati.
• Il costo del ridimensionamento di un SIEM OSS è costituito principalmente dai prezzi per l’hardware aggiuntivo e dallo sviluppo delle funzionalità coerenti richieste.
• Sia la configurazione iniziale che l’evoluzione in corso di un SIEM OSS richiedono professionisti esperti sia nelle pratiche di sviluppo che nelle realtà SOC. Se i membri del team che comprendono meglio il sistema lasciano l’azienda o cambiano ruolo, l’evoluzione del sistema potrebbe interrompersi. Quel che è peggio, diventa gradualmente meno funzionale.
• Sebbene il costo di implementazione iniziale di un SIEM OSS possa essere inferiore a causa dell’assenza di canoni di licenza, questa differenza spesso si riduce durante la fase di manutenzione. Ciò è dovuto alla spesa aggiuntiva continua per il personale qualificato dedicato esclusivamente allo sviluppo SIEM. Nel lungo termine, il costo totale di proprietà (TCO) di un SIEM OSS spesso risulta essere più elevato.

Qualità dei contenuti

La pertinenza del contenuto di rilevamento e risposta è un fattore chiave per l’efficacia di un SIEM. Per le soluzioni commerciali, gli aggiornamenti delle regole di correlazione, i playbook e i feed di intelligence sulle minacce vengono in genere forniti come parte di un abbonamento. Sono sviluppati da ampi team di ricercatori, sono sottoposti a test approfonditi e in genere richiedono il minimo sforzo da parte del team di sicurezza interno per l’implementazione. Con un OSS SIEM, si è soli in fatto di aggiornamenti: è necessario eseguire manualmente la ricerca nei forum della community, negli archivi GitHub e nei feed gratuiti. Le regole richiedono quindi un controllo dettagliato e l’adattamento all’infrastruttura specifica e il rischio di falsi positivi finisce per essere maggiore. Di conseguenza, l’implementazione degli aggiornamenti in un SIEM open source richiede uno sforzo notevolmente maggiore da parte del team interno.

Un problema ben noto: l’hardware

Per avviare un SIEM, è necessario acquisire o noleggiare hardware e, a seconda dell’architettura del sistema, questa spesa può variare notevolmente. Non ha molta importanza se il sistema è una soluzione commerciale open source o proprietaria. Tuttavia, quando si implementa autonomamente un SIEM open source, esiste un rischio maggiore di prendere decisioni sull’architettura non ottimali. A lungo termine, questo si traduce in costi operativi costantemente elevati.

L’argomento della valutazione delle esigenze hardware SIEM verrà trattato in dettaglio in un post separato.

Il conto finale

Sebbene l’idea di una piattaforma completamente personalizzabile e adattabile senza costi di licenza sia molto allettante, esiste il rischio significativo che un progetto del genere richieda molto più tempo e sforzi da parte del team di sviluppo interno di una soluzione commerciale standard. Può inoltre ostacolare la capacità di adottare rapidamente nuove innovazioni e spostare l’attenzione del team di sicurezza dallo sviluppo della logica di rilevamento dagli scenari di risposta alla gestione primaria dei problemi operativi. Questo è il motivo per cui una soluzione commerciale gestita, supportata da esperti e ben integrata spesso si allinea maggiormente agli obiettivi tipici di un’organizzazione di riduzione effettiva dei rischi e budgeting prevedibile.

I SIEM commerciali consentono al team di sfruttare regole predefinite, playbook e parser di telemetria, permettendogli di concentrarsi su progetti specifici dell’organizzazione, come la ricerca delle minacce o il miglioramento della visibilità nell’infrastruttura cloud, anziché reinventare e perfezionare le funzionalità SIEM di base o superare gli audit normativi con un sistema locale.