La Teoria e la Realtà del ROI del SIEM

Molte cose sono state scritte sui SIEM, eppure la mia esperienza personale con questi meravigliosi strumenti è iniziata nel 2007. Oggi la tecnologia stessa ha più di 18 anni e il mercato dei SIEM è ormai maturo sotto ogni aspetto. Insieme a clienti, team e partner ho avuto il privilegio di partecipare attivamente a più di un centinaio di progetti SIEM in tutto il mondo. Insieme abbiamo costruito SOC da zero, implementato fonti di log critiche per SOX per rispettare scadenze auditive strette, resuscitato un’installazione SIEM abbandonata in mezza giornata per individuare indizi forensi e condotto messa a punto fine delle regole di correlazione anti-frode… e semplicemente preso una giusta quantità di birra insieme ad aziende di tutti i settori e parti del mondo discutendo storia di vittorie e sconfitte dei progetti SIEM. È noto che oltre 40 mila organizzazioni nel mondo dispongono di sistemi SIEM, quindi questa è una comunità piuttosto ampia e ovviamente un mercato. Ciò che è certo è che la storia è tutt’altro che finita poiché il concetto stesso di SIEM continua la sua evoluzione. La maggior parte delle organizzazioni che non sono indifferenti alla sicurezza informatica hanno già un SIEM in una forma o nell’altra. I confini tra le tecnologie SIEM sono sfumati: esistono la prima, la seconda e la terza generazione della piattaforma, sebbene affermare che IBM QRadar o Micro Focus ArcSight siano tecnologie di prima generazione e LogRhythm di seconda non sia del tutto corretto, poiché le tecnologie sono in costante evoluzione. Inoltre, sostenere che Splunk ed Elastic non siano un SIEM è errato poiché hanno molte proprietà e funzionalità SIEM.

Quindi come si uniscono SIEM e ROI? Se consideriamo il ROI dal punto di vista di qualsiasi business significherebbe o un profitto aggiuntivo o una riduzione dei costi. Si possono fare molti esempi sul ritorno dell’investimento nella sicurezza delle informazioni, sufficienti per scrivere un articolo separato, quindi per ora concentriamoci sul SIEM. È difficile credere che qualcuno investa in questi sistemi per guadagnare denaro, quindi restiamo con il motore della riduzione dei costi. Cerchiamo di capirlo.

Come appaiono i SIEM nelle nostre vite?
5 dr ivers di ROI fondamentali

1. Conformità
2. Archivio centrale di log
3. Analisi forense
4. Security Operations Center (SOC)
5. Eredità

SIEM per la conformità PCI, SOX e HIPAA

Molto spesso, i SIEM vengono acquistati da istituzioni finanziarie e banche poiché varie normative di conformità richiedono la raccolta e l’elaborazione dei dati di log. PCI DSS richiede la raccolta centrale dei dati di log, la loro memorizzazione e conservazione in forma non modificata, fornire una traccia di audit della loro integrità (un requisito molto importante che non tutti i SIEM possono soddisfare ancora oggi) e ovviamente monitorare gli eventi quotidianamente. Se dobbiamo rispettare SOX, è necessario monitorare e gestire gli incidenti di tutti i sistemi critici di SOX e, in base a questo, gli auditor o si fidano o non si fidano dei dati aziendali nei sistemi elaborati. Se gli incidenti non vengono gestiti, l’audit diventa molto più costoso. Un altro esempio è la conformità HIPAA con il requisito di mantenere una traccia di audit sull’accesso ai dati dei pazienti per un periodo fino a 5 anni. Questo influenza principalmente l’architettura del processamento dati SIEM: la flessibilità delle capacità di integrazione del sistema di terze parti, l’efficienza e la stabilità dell’aggregazione, gli algoritmi di compressione dati così come il controllo dell’integrità.

Quindi, quale tipo di ROI può generare un SIEM per la conformità? Il più chiaro è l’assenza di multe e sanzioni grazie al non solo seguire ma superare i requisiti delle normative. Questo rappresenta un eccellente ritorno sull’investimento dal SIEM poiché l’investimento nel progetto sarà probabilmente almeno 10 volte inferiore alla penalità per violazione della conformità. È consigliato creare un modello TCO quinquennale che includa tutte le spese come supporto, hardware, costo del software, costo del team, programma di formazione e di fidelizzazione. Quindi abbinare il TCO con i risparmi possibili sulle violazioni di conformità in base ai rischi che affrontate. Questo renderebbe il ROI giustificato non solo sulla carta e aiuterebbe a evitare errori di calcolo.

Archivio centrale di log

Il modo migliore per calcolare il ROI dall’uso del SIEM come archivio centrale di log è abbastanza semplice: determinare quali dati di log dobbiamo raccogliere e memorizzare, quanto spazio richiederanno, le specifiche hardware e il carico di lavoro per questo compito. È necessario considerare tutti i parametri dal spazio HDD al costo di 1 core CPU (specialmente le distribuzioni basate su cloud e virtualizzazione). Tutti i sistemi di gestione e SIEM dei log sono molto bravi a comprimere i dati di log con un’efficienza da 2X a oltre 10X, il che porta a risparmi diretti sull’archiviazione, anche se viene eseguito l’arricchimento e la normalizzazione dei dati. La capacità di un particolare SIEM di ottimizzare in modo granulare l’aggregazione dei dati di log e il filtraggio migliorerà direttamente l’efficienza di archiviazione e il ROI. L’aggregazione è presente in qualsiasi piattaforma SIEM matura, praticamente tutti i sistemi che vedi in Gartner hanno qualche tipo di aggregazione. Le capacità variano da fornitore a fornitore: molto spesso è solo un pulsante on/off, mentre in altre tecnologie abbiamo oltre 9000 parametri che possono essere configurati per adattarsi a qualsiasi infrastruttura.

I SIEM sono costruiti per supportare la ricerca rapida e la fornitura tempestiva di informazioni. Inoltre, utilizziamo la tecnologia per semplificare il backup e la gestione dei dati di log. Sorprendentemente, è molto più facile gestire un sistema di archiviazione log centralizzato piuttosto che curarsi di ciascuna fonte del log singolarmente. Gli archivi creati dai SIEM molto spesso hanno un controllo di integrità incorporato e sono difficili da manomettere: sono criptati o creati come un unico contenitore dove rompere l’integrità del contenitore non passa inosservato. Tutti i SIEM maturi controllano l’integrità di tali contenitori e la conservazione dei log.

Vediamo spesso come i progetti SIEM nascono sia come iniziative IT che di sicurezza principalmente per ragioni di risparmio sulla conservazione dei dati di log. Questo è particolarmente vero per le piattaforme Splunk ed Elasticsearch poiché entrambe sono più adatte per questo compito. Uno scenario tipico qui è quando il dipartimento IT ottiene supporto gestionale e finanziamenti per il progetto, ottiene la piattaforma e poi il team di sicurezza ottiene una licenza aggiuntiva come aggiornamento poiché l’integrazione delle tecnologie dallo stesso fornitore riduce il TCO e semplifica il supporto.

ROI sulle operazioni forensi proattive

Avere un archivio centralizzato sicuro di tutti i dati di log apre una strada per il ROI sulla forense: i log sono memorizzati in formato non modificato a prova di manomissione, supportano ricerche rapide, pivoting e tutto ciò è fattibile in un tempo ragionevole se abbiamo fatto il nostro impianto SIEM correttamente. Pertanto, la nostra indagine sugli incidenti può essere effettuata più velocemente e ottenere le prove diventa più semplice. Quando ci serve davvero questo? Beh, se la nostra esperienza di infosec ci ha insegnato qualcosa è che quando si verifica un incidente la maggior parte delle organizzazioni non ha esperti a tempo pieno per condurre un’indagine e questa responsabilità ricade in un modo o nell’altro sulla divisione sicurezza delle informazioni (o cyber). Solo le grandi organizzazioni e il settore pubblico possono permettersi di allocare un dipendente per queste finalità. E agli occhi del business, la forense è un costo significativo per l’azienda che non può essere evitato. Se il SIEM ha tutti i dati necessari, allora uno specialista CHFI condurrà un’indagine molto più veloce e si concentrerà sull’obiettivo principale – trovare l’avversario e le prove. È molto più facile condurre un’indagine quando i dati di log sono disponibili nel loro formato originale, rapporti predefiniti ed esportazioni esistono effettivamente e non impiegano giorni per essere ottenuti, dump di traffico (PCAP) sono disponibili e possiamo anche avere eventi di sicurezza sospetti alias statistiche su incidenti per costruire meglio il quadro completo. Nella situazione opposta, uno specialista forense sarà costretto a scavare a fondo e probabilmente a viaggiare sul posto e raccogliere personalmente i dati necessari dai server bit per bit. In quest’ultima situazione, il tempo per effettuare un’adeguata indagine aumenta ciò che direttamente aumenta i costi della forense o ne diminuisce la qualità fino a un livello dove il risultato finale può essere deludente. Se l’incidente non è mai accaduto è pressoché impossibile calcolare il ROI sulla forense proattiva. Anche se se guardiamo alla tendenza crescente delle violazioni dei dati, attacchi APT e statistiche sugli incidenti cyber e abbracciamo la realtà, ci rendiamo conto che prima o poi qualsiasi organizzazione viene violata. E subire una violazione inevitabilmente porta a impegnarsi in un’indagine forense direttamente o indirettamente per qualsiasi CISO.

SIEM e Forense nella vita reale

Qualche tempo fa abbiamo lavorato a stretto contatto con il nostro partner per investigare su un possibile attacco insider. Quando siamo arrivati in sede non c’era né SIEM né un sistema centrale di gestione dei log e proprio come nei classici qualcuno aveva cancellato i log ovunque ne avesse avuto la possibilità, i backup non erano stati eseguiti, gli ACL non c’erano, nessun file PCAP era disponibile. Abbiamo analizzato le immagini target, inviato dati al laboratorio per il recupero, fatto alcune navigazioni nel darknet e scavi. Di conseguenza la gestione del cliente ha pagato per 5 giorni di forense + tempo per la relazione e la presentazione, che hanno dimostrato le tracce e i danni dell’attacco insider, ma poiché l’azienda non aveva gestione dei log e SIEM era impossibile attribuire questo attacco a una persona specifica, quindi l’attribuzione è stata il modo migliore per finalizzare l’indagine. L’azienda avrebbe potuto investire più risorse nel recupero dati, ma la stima era un altro 30 giorni che a tutti gli effetti è un’impresa piuttosto costosa quindi non abbiamo davvero consigliato ciò. Il cliente era soddisfatto del risultato considerando che in realtà non abbiamo trovato nulla? Sì, hanno ottenuto i risultati di un’indagine ufficiale utilizzabile in tribunale. Anche se IMHO questo è un motivo molto costoso per verificare se un sistema SIEM è necessario in azienda.

C’è anche un piccolo esempio della storia di successo dell’ROI del SIEM nell’indagine di attacco APT nel 2015-2016, quando abbiamo agito come consulenti nell’indagine di incidenti che sembravano parte con l’attacco APT BlackEnergy. L’azienda target dell’APT stava eseguendo un’implementazione PoC di SIEM (in questo caso era Arcsight) che ha essenzialmente aiutato a trovare i codici di log degli eventi Microsoft che hanno mostrato la sequenza di installazione di un nuovo servizio e abbiamo scoperto come i driver malevoli sono stati iniettati nel sistema. Poiché tutti i log di audit sono stati eliminati sui sistemi attaccati (BlackEnergy e KillDisk) il SIEM stava funzionando su Unix e nel segmento isolato, quindi BlackEnergy non lo ha raggiunto (KillDisk per Unix non esisteva/ non esiste). Quindi in questo caso il SIEM ha aiutato a preservare le tracce dell’attacco ed è stato il primo indizio per iniziare l’indagine forense completa.

Misurare l’ROI del SOC

Il driver più comune per l’implementazione di un SIEM è costruire un centro per un monitoraggio proattivo degli incidenti di sicurezza al fine di identificarli tempestivamente e ridurre preventivamente i rischi. Quindi fondamentalmente costruire un SOC è una ragione comune per acquistare un SIEM. Il compito principale del sistema SIEM in un SOC è eseguire ogni tipo di correlazione di eventi e trovare ciò che un essere umano fisicamente non può a causa dei volumi di dati che devono essere analizzati. Oggigiorno i SIEM sono in grado di elaborare miliardi di eventi al giorno, centinaia di migliaia o addirittura più di un milione di EPS e fornire informazioni in una forma adatta per analisi rapide e con tutti gli strumenti di investigazione necessari. Soddisfare questi requisiti unisce Conformità, Forense e Archivio Centrale di Log attorno al SOC e li eleva a un livello completamente nuovo.

Determinare l’ROI del SOC è un grande argomento, tuttavia nelle sue basi è necessario monitorare e contare tutti gli incidenti rilevati e modellare i danni prevenuti in una fase iniziale. È necessario costruire e mantenere continuamente un modello di asset e rete dell’azienda, il costo e il valore degli asset IT, i rischi applicabili, idealmente costruire anche un modello CVSS. In base al costo degli incidenti su questi asset sarà possibile determinare il potenziale danno prevenuto. Il SIEM stesso inoltre risparmia il tempo degli analisti e aiuta a trovare quelle ore extra necessarie per altri compiti di sicurezza come rispondere a richieste di audit e gestione del rischio, eseguire analisi delle cause principali e indagini.

I casi d’uso SIEM fanno un patrimonio prezioso

L’ultimo caso che spesso vediamo è una situazione in cui qualcuno eredita il SIEM. Nessuno sa perché il sistema sia stato acquisito in primo luogo perché i dipendenti iniziali hanno lasciato, nuovi sono arrivati e questa situazione si espande a tutti i livelli, dai manager al personale sul campo. Immagina questo: arrivi a lavorare in una nuova organizzazione che abbia un SIEM. La direzione dice: “Abbiamo integrato tutti i log di audit e è costato all’azienda parecchie migliaia/milioni di dollari… Sicuramente puoi farci qualcosa? Voglio dire, il compito a portata di mano è abbastanza semplice, abbiamo documenti, la tecnologia è matura e tutto funziona quasi perfettamente! Quindi basta qualche ritocco qua e là e avremo una consapevolezza totale della sicurezza e visibilità della rete. Questo sarebbe molto utile!” Un progetto SIEM ambizioso o addirittura SOC dovrebbe essere iniziato con qualcosa di semplice. Questo è in realtà ROI nella sua forma più pura. Qui dobbiamo concentrarci su successi veloci per mostrare che la tecnologia è stata acquistata per una buona ragione. Per avere successo con questo compito è meglio scegliere casi d’uso già costruiti e testati per le tecnologie che avete nella vostra organizzazione e scegliere soluzioni mirate su minacce e rischi specifici che sono più attivi sul campo, come Ransomware, APT, Monitoraggio di Windows, VPN, sicurezza SSL. E poi dovremmo rapidamente regolarli per adattarli ai driver ROI.

Perché il ROI del SIEM è così buono in teoria eppure così lontano dalla realtà?

Una lezione dall’aver sorvegliato oltre un centinaio di implementazioni: solo perché un sistema SIEM è implementato in un’organizzazione non significa che raccolga tutti i dati pianificati e collegati durante la fase di integrazione iniziale. L’integrazione è un processo, chiamalo continuo se vuoi. E la mancanza di dati = assenza di ROI. E non si tratta solo di acquisizione: come qualsiasi sistema analitico il SIEM segue il principio “garbage in = garbage out”. In poche parole non produrrà i tuoi buoni risultati se le sfide dei dati vengono ignorate e in caso di audit di conformità, i dati richiesti potrebbero non essere disponibili se non vengono monitorati la Qualità dei Dati e l’Acquisizione dei Dati. Sappiamo anche che l’infrastruttura IT di qualsiasi azienda non è statica, l’architettura cambia costantemente man mano che nuovi servizi vengono introdotti e dismessi, il formato e il trasporto dei dati di log cambiano, la configurazione del firmware e del sistema operativo cambia e questo rende il parsing degli eventi per garantire la Qualità dei Dati un processo che deve essere continuamente perfezionato. Se la qualità non è controllata con almeno 0,25 FTE per il compito allora l’utilità dei dati diminuirà costantemente e al momento, diciamo, dell’audit PCI l’azienda potrebbe non passarlo. Problemi di performance possono anche portare a una situazione in cui i rapporti falliscono proprio quando ne hai bisogno e di solito è quando gli auditor o la gestione li richiedono “per ieri”. Questo è particolarmente critico per SOX.

Il SIEM non è autosufficiente: indipendentemente dal fatto che sia su software on premise o su SaaS ha bisogno di personale formato che sia parte del team interno o parte del servizio di outsourcing. Calcoli d’investimento errati accadono piuttosto spesso per i progetti SIEM. Gli investimenti nella tecnologia SIEM durante i primi 5 anni dovrebbero costituire solo il 20-30% del budget totale del progetto. È necessario investire in attrezzature e nel team, specialmente nella formazione, ritenzione del personale e scalabilità delle operazioni. Un altro errore è supporre che acquistare SIEM ridurrà significativamente il carico di lavoro, al contrario introdurrà in realtà una serie di nuovi compiti e competenze richieste. I tuoi esperti semplicemente ricevono l’opportunità di lavorare con enormi quantità di dati di sicurezza, analizzarli e dar loro significato per ridurre i rischi, qualcosa che era precedentemente impossibile. Pertanto, un’errata pianificazione delle risorse è un altro motivo per cui non è possibile ottenere un ROI dal SIEM.

Infine, un approccio all’implementazione dei Use Cases per SIEM richiede la comprensione che i casi d’uso non sono implementati come una cosa una tantum, e la loro qualità degraderà rapidamente se non vengono migliorati e ottimizzati continuamente. La soluzione più efficace e allo stesso tempo semplice è quella di utilizzare i casi d’uso già disponibili e non reinventare la ruota (casi per il monitoraggio di Windows, Cisco, antivirus, ecc.). È necessario concentrare gli sforzi del team sullo sviluppo di casi d’uso specifici per la tua organizzazione. Per verificare che stiamo costruendo i casi d’uso richiesti: se il caso d’uso può essere copiato nel SIEM di un’altra azienda e funzionerà lì con lo stesso valore, significa che è universale. E c’è un’alta probabilità che sia già disponibile come pacchetto freemium o commerciale che richiede nessun tuning minimo per produrre valore di sicurezza.

Pertanto, possiamo definire 5 processi che assicurano un ROI positivo dal SIEM

1. Monitoraggio e mantenimento dell’Acquisizione Dati e della Qualità dei Dati
2. Monitoraggio, mantenimento e miglioramento continuo dei Use Cases del SIEM
3. Pianificazione tecnica adeguata del progetto e dell’architettura
4. Pianificazione e regolazione dell’FTE in anticipo per prevenire il sovraccarico del team
5. Un piano chiaro per l’investimento nel team: formazione, ritenzione e sviluppo

Quindi qui abbiamo i modi principali per ottenere il ROI dal SIEM e alcune ragioni sul perché non sempre funzionano come previsto. Qual è la tua esperienza nell’ottenere ROI da un SIEM?